diff --git a/e2e/utils/index.ts b/e2e/utils/index.ts index b0b2c524c4..cbd2f0ed42 100644 --- a/e2e/utils/index.ts +++ b/e2e/utils/index.ts @@ -12,7 +12,7 @@ import { statSync, writeFileSync, } from 'fs-extra'; -import * as isCI from 'is-ci'; +import isCI = require('is-ci'); import * as path from 'path'; import { dirSync } from 'tmp'; diff --git a/jest.config.js b/jest.config.js index b3e8e91067..957dd7bdd5 100644 --- a/jest.config.js +++ b/jest.config.js @@ -19,6 +19,10 @@ module.exports = { '/packages/cli', '/packages/angular', '/packages/gatsby', - '/dep-graph/dep-graph-client', + '/dep-graph/dep-graph', + '/nx-dev/nx-dev', + '/nx-dev/ui-common', + '/nx-dev/feature-doc-viewer', + '/nx-dev/data-access-documents', ], }; diff --git a/jest.preset.js b/jest.preset.js index 71f459b769..d82132fa31 100644 --- a/jest.preset.js +++ b/jest.preset.js @@ -1,4 +1,5 @@ const nxPreset = require('@nrwl/jest/preset'); + module.exports = { ...nxPreset, testTimeout: 30000, diff --git a/nx-dev/README.md b/nx-dev/README.md new file mode 100644 index 0000000000..a31f80ad1f --- /dev/null +++ b/nx-dev/README.md @@ -0,0 +1,3 @@ +# nx.dev + +This folder contains the app and libs to power [nx.dev](https://nx.dev)). diff --git a/nx-dev/data-access-documents/.babelrc b/nx-dev/data-access-documents/.babelrc new file mode 100644 index 0000000000..0cae4a9a81 --- /dev/null +++ b/nx-dev/data-access-documents/.babelrc @@ -0,0 +1,3 @@ +{ + "presets": ["@nrwl/web/babel"] +} diff --git a/nx-dev/data-access-documents/.eslintrc.json b/nx-dev/data-access-documents/.eslintrc.json new file mode 100644 index 0000000000..ee27ad3f41 --- /dev/null +++ b/nx-dev/data-access-documents/.eslintrc.json @@ -0,0 +1,21 @@ +{ + "extends": ["../../.eslintrc.json"], + "ignorePatterns": ["!**/*"], + "overrides": [ + { + "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], + "parserOptions": { + "project": ["nx-dev/data-access-documentation/tsconfig.*?.json"] + }, + "rules": {} + }, + { + "files": ["*.ts", "*.tsx"], + "rules": {} + }, + { + "files": ["*.js", "*.jsx"], + "rules": {} + } + ] +} diff --git a/nx-dev/data-access-documents/README.md b/nx-dev/data-access-documents/README.md new file mode 100644 index 0000000000..5ae32a3856 --- /dev/null +++ b/nx-dev/data-access-documents/README.md @@ -0,0 +1,11 @@ +# documentation-api + +This library provides the data necessary to display the latest and previous documentation. + +The [`data`](./src/data) folder contains the version mapping as well as a snapshot of the latest and previous docs. + +## Testing + +``` +nx test documentation-api +``` diff --git a/nx-dev/data-access-documents/jest.config.js b/nx-dev/data-access-documents/jest.config.js new file mode 100644 index 0000000000..f962ebf495 --- /dev/null +++ b/nx-dev/data-access-documents/jest.config.js @@ -0,0 +1,15 @@ +const nxPreset = require('@nrwl/jest/preset'); +module.exports = { + ...nxPreset, + displayName: 'nx-dev-data-access-documents', + globals: { + 'ts-jest': { + tsConfig: '/tsconfig.spec.json', + }, + }, + transform: { + '^.+\\.[tj]sx?$': 'ts-jest', + }, + moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx'], + coverageDirectory: '../../../coverage/nx-dev/data-access-documents', +}; diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/ng-packagr-lite.md new file mode 100644 index 0000000000..c03f75dee5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/ng-packagr-lite.md @@ -0,0 +1,35 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/package.md new file mode 100644 index 0000000000..506a5054ce --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/package.md @@ -0,0 +1,45 @@ +# package + +Build and package an Angular library for publishing + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/webpack-browser.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/webpack-browser.md new file mode 100644 index 0000000000..4fd34e498c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/builders/webpack-browser.md @@ -0,0 +1,333 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +Type: `boolean` + +Log progress to the console while building. + +### rebaseRootRelativeCssUrls + +Default: `false` + +Type: `boolean` + +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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/application.md new file mode 100644 index 0000000000..21d84d5a9e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 `angular.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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/downgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/downgrade-module.md new file mode 100644 index 0000000000..bf61edc6e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup Downgrade Module + +## Usage + +```bash +nx generate downgrade-module ... +``` + +By default, Nx will search for `downgrade-module` in the default collection provisioned in `angular.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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma-project.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma-project.md new file mode 100644 index 0000000000..437525907f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing to a project + +## Usage + +```bash +nx generate karma-project ... +``` + +By default, Nx will search for `karma-project` in the default collection provisioned in `angular.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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma.md new file mode 100644 index 0000000000..60e8a1287f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/karma.md @@ -0,0 +1,23 @@ +# karma + +Add karma configuration to a workspace + +## Usage + +```bash +nx generate karma ... +``` + +By default, Nx will search for `karma` in the default collection provisioned in `angular.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 +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/library.md new file mode 100644 index 0000000000..2bef93086b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/library.md @@ -0,0 +1,177 @@ +# library + +Create 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 `angular.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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### 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. 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/move.md new file mode 100644 index 0000000000..194b230d65 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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 `angular.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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/ngrx.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/ngrx.md new file mode 100644 index 0000000000..2b80efe29e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## Usage + +```bash +nx generate ngrx ... +``` + +By default, Nx will search for `ngrx` in the default collection provisioned in `angular.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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/stories.md new file mode 100644 index 0000000000..f78a30e2a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/stories.md @@ -0,0 +1,37 @@ +# 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 `angular.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 + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/storybook-configuration.md new file mode 100644 index 0000000000..22c0c2f577 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a library + +## Usage + +```bash +nx generate storybook-configuration ... +``` + +By default, Nx will search for `storybook-configuration` in the default collection provisioned in `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library + +### linter + +Default: `tslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/upgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/upgrade-module.md new file mode 100644 index 0000000000..5ef0b73705 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-angular/schematics/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add an upgrade module + +## Usage + +```bash +nx generate upgrade-module ... +``` + +By default, Nx will search for `upgrade-module` in the default collection provisioned in `angular.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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/angular/api-cypress/builders/cypress.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-cypress/builders/cypress.md new file mode 100644 index 0000000000..c940e55be1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-cypress/builders/cypress.md @@ -0,0 +1,125 @@ +# cypress + +Run Cypress e2e tests + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/10.4.13/angular/api-express/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-express/schematics/application.md new file mode 100644 index 0000000000..fa4f5a0ae5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-express/schematics/application.md @@ -0,0 +1,115 @@ +# 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 `angular.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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/angular/api-jest/builders/jest.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-jest/builders/jest.md new file mode 100644 index 0000000000..beca0edde6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-jest/builders/jest.md @@ -0,0 +1,221 @@ +# jest + +Run Jest unit tests + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/eslint.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/eslint.md new file mode 100644 index 0000000000..0886f1080d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/eslint.md @@ -0,0 +1,93 @@ +# eslint + +Run ESLint on a project + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/lint.md new file mode 100644 index 0000000000..ebe4e1a3ff --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-linter/builders/lint.md @@ -0,0 +1,109 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/application.md new file mode 100644 index 0000000000..a8033843a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest application + +## Usage + +```bash +nx generate application ... +``` + +```bash +nx g app ... # same +``` + +By default, Nx will search for `application` in the default collection provisioned in `angular.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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/class.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/class.md new file mode 100644 index 0000000000..60eed0c9de --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/class.md @@ -0,0 +1,65 @@ +# class + +Run the 'class' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate class ... +``` + +By default, Nx will search for `class` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/controller.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/controller.md new file mode 100644 index 0000000000..34196e0344 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/controller.md @@ -0,0 +1,65 @@ +# controller + +Run the 'controller' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate controller ... +``` + +By default, Nx will search for `controller` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/decorator.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/decorator.md new file mode 100644 index 0000000000..91251f6129 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/decorator.md @@ -0,0 +1,65 @@ +# decorator + +Run the 'decorator' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate decorator ... +``` + +By default, Nx will search for `decorator` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/filter.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/filter.md new file mode 100644 index 0000000000..e9fdd2d25f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/filter.md @@ -0,0 +1,65 @@ +# filter + +Run the 'filter' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate filter ... +``` + +By default, Nx will search for `filter` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/gateway.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/gateway.md new file mode 100644 index 0000000000..17337b1310 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/gateway.md @@ -0,0 +1,65 @@ +# gateway + +Run the 'gateway' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate gateway ... +``` + +By default, Nx will search for `gateway` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/guard.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/guard.md new file mode 100644 index 0000000000..957a746595 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/guard.md @@ -0,0 +1,65 @@ +# guard + +Run the 'guard' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate guard ... +``` + +By default, Nx will search for `guard` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interceptor.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interceptor.md new file mode 100644 index 0000000000..7fe958dbe3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interceptor.md @@ -0,0 +1,65 @@ +# interceptor + +Run the 'interceptor' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate interceptor ... +``` + +By default, Nx will search for `interceptor` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interface.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interface.md new file mode 100644 index 0000000000..3d3caeeb6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/interface.md @@ -0,0 +1,65 @@ +# interface + +Run the 'interface' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate interface ... +``` + +By default, Nx will search for `interface` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/library.md new file mode 100644 index 0000000000..378edce0f3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/library.md @@ -0,0 +1,159 @@ +# library + +Create a new nest library + +## Usage + +```bash +nx generate library ... +``` + +```bash +nx g lib ... # same +``` + +By default, Nx will search for `library` in the default collection provisioned in `angular.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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/middleware.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/middleware.md new file mode 100644 index 0000000000..f0bbc032b3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/middleware.md @@ -0,0 +1,65 @@ +# middleware + +Run the 'middleware' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate middleware ... +``` + +By default, Nx will search for `middleware` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/module.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/module.md new file mode 100644 index 0000000000..fadf38a320 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/module.md @@ -0,0 +1,65 @@ +# module + +Run the 'module' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate module ... +``` + +By default, Nx will search for `module` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/pipe.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/pipe.md new file mode 100644 index 0000000000..aa4f795996 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/pipe.md @@ -0,0 +1,65 @@ +# pipe + +Run the 'pipe' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate pipe ... +``` + +By default, Nx will search for `pipe` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/provider.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/provider.md new file mode 100644 index 0000000000..aeec1a7e37 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/provider.md @@ -0,0 +1,65 @@ +# provider + +Run the 'provider' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate provider ... +``` + +By default, Nx will search for `provider` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/resolver.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/resolver.md new file mode 100644 index 0000000000..11f796c622 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/resolver.md @@ -0,0 +1,65 @@ +# resolver + +Run the 'resolver' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate resolver ... +``` + +By default, Nx will search for `resolver` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/service.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/service.md new file mode 100644 index 0000000000..64eba5d6dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nest/schematics/service.md @@ -0,0 +1,65 @@ +# service + +Run the 'service' NestJs Schematic with Nx project support + +## Usage + +```bash +nx generate service ... +``` + +By default, Nx will search for `service` in the default collection provisioned in `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/build.md new file mode 100644 index 0000000000..c1c48a58cb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/build.md @@ -0,0 +1,43 @@ +# build + +Build a Next.js app + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/export.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/export.md new file mode 100644 index 0000000000..830302d8b3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/export.md @@ -0,0 +1,27 @@ +# export + +Export a Next.js app. The exported application is located at dist/\$outputPath/exported. + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### 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/data-access-documents/src/data/10.4.13/angular/api-next/builders/server.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/server.md new file mode 100644 index 0000000000..8f0510f261 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/builders/server.md @@ -0,0 +1,63 @@ +# server + +Serve a Next.js app + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/angular/api-next/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/application.md new file mode 100644 index 0000000000..1edfc0e647 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/application.md @@ -0,0 +1,123 @@ +# 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 `angular.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 + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style) + +### 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. + +### 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/data-access-documents/src/data/10.4.13/angular/api-next/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/component.md new file mode 100644 index 0000000000..a15559d721 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/component.md @@ -0,0 +1,107 @@ +# component + +Create a React component + +## Usage + +```bash +nx generate component ... +``` + +By default, Nx will search for `component` in the default collection provisioned in `angular.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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/angular/api-next/schematics/page.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/page.md new file mode 100644 index 0000000000..913c30ad49 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-next/schematics/page.md @@ -0,0 +1,107 @@ +# 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 `angular.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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/angular/api-node/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/build.md new file mode 100644 index 0000000000..219d41f303 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/build.md @@ -0,0 +1,161 @@ +# build + +Build a Node application + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### buildLibsFromSource + +Default: `false` + +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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/execute.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/execute.md new file mode 100644 index 0000000000..73f1a5c3f0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/execute.md @@ -0,0 +1,63 @@ +# execute + +Execute a Node application + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/10.4.13/angular/api-node/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/package.md new file mode 100644 index 0000000000..1799dcda7b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/builders/package.md @@ -0,0 +1,77 @@ +# package + +Package a Node library + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/angular/api-node/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/schematics/application.md new file mode 100644 index 0000000000..e5beb3332a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/schematics/application.md @@ -0,0 +1,115 @@ +# 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 `angular.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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/angular/api-node/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/schematics/library.md new file mode 100644 index 0000000000..40b589c3f7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-node/schematics/library.md @@ -0,0 +1,159 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/builders/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/builders/e2e.md new file mode 100644 index 0000000000..816558d0d0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/builders/e2e.md @@ -0,0 +1,25 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/builder.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/builder.md new file mode 100644 index 0000000000..834d5e6a0e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/builder.md @@ -0,0 +1,65 @@ +# builder + +Create a builder for an Nx Plugin + +## Usage + +```bash +nx generate builder ... +``` + +By default, Nx will search for `builder` in the default collection provisioned in `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:builder ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g builder ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/builders/my-builder: + +```bash +nx g builder my-builder --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Builder description + +### name + +Type: `string` + +Builder name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/migration.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/migration.md new file mode 100644 index 0000000000..c3d3a9d3a8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/migration.md @@ -0,0 +1,83 @@ +# 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 `angular.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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/plugin.md new file mode 100644 index 0000000000..656fff8080 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/plugin.md @@ -0,0 +1,97 @@ +# plugin + +Create a Nx Plugin + +## Usage + +```bash +nx generate plugin ... +``` + +By default, Nx will search for `plugin` in the default collection provisioned in `angular.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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/schematic.md new file mode 100644 index 0000000000..926215122b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-nx-plugin/schematics/schematic.md @@ -0,0 +1,65 @@ +# schematic + +Create a schematic for an Nx Plugin + +## Usage + +```bash +nx generate schematic ... +``` + +By default, Nx will search for `schematic` in the default collection provisioned in `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g schematic ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/schematics/my-schematic: + +```bash +nx g schematic my-schematic --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Schematic description + +### name + +Type: `string` + +Schematic name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/application.md new file mode 100644 index 0000000000..1c545946a6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/application.md @@ -0,0 +1,165 @@ +# 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 `angular.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. + +### 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. + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style). + +### 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/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-cypress-spec.md new file mode 100644 index 0000000000..5496c40fde --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 `angular.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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-story.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-story.md new file mode 100644 index 0000000000..9dc2d510af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component-story.md @@ -0,0 +1,37 @@ +# 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 `angular.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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component.md new file mode 100644 index 0000000000..e0734c9b23 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/component.md @@ -0,0 +1,137 @@ +# component + +Create a component + +## Usage + +```bash +nx generate component ... +``` + +```bash +nx g c ... # same +``` + +By default, Nx will search for `component` in the default collection provisioned in `angular.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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/angular/api-react/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/library.md new file mode 100644 index 0000000000..247ca15750 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/library.md @@ -0,0 +1,173 @@ +# 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 `angular.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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### directory + +Alias(es): d + +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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/angular/api-react/schematics/redux.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/redux.md new file mode 100644 index 0000000000..762c61dba7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/redux.md @@ -0,0 +1,67 @@ +# 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 `angular.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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/10.4.13/angular/api-react/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/stories.md new file mode 100644 index 0000000000..27511a4e98 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/stories.md @@ -0,0 +1,45 @@ +# 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 `angular.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 + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic. + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/storybook-configuration.md new file mode 100644 index 0000000000..3d7b940a94 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-react/schematics/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/build.md new file mode 100644 index 0000000000..6d16ae6db7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/build.md @@ -0,0 +1,37 @@ +# build + +Build Storybook + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/storybook.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/storybook.md new file mode 100644 index 0000000000..58f6cd165b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/builders/storybook.md @@ -0,0 +1,81 @@ +# storybook + +Serve Storybook + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### port + +Default: `9009` + +Type: `number` + +Port to listen on. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/configuration.md new file mode 100644 index 0000000000..85424203c1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/configuration.md @@ -0,0 +1,63 @@ +# configuration + +Add storybook configuration to a ui library + +## Usage + +```bash +nx generate configuration ... +``` + +By default, Nx will search for `configuration` in the default collection provisioned in `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### 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` + +Library name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/cypress-project.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/cypress-project.md new file mode 100644 index 0000000000..2c41f37dd5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-storybook/schematics/cypress-project.md @@ -0,0 +1,49 @@ +# 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 `angular.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 + +### 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` + +Library name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/build.md new file mode 100644 index 0000000000..be67fd7ff7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/build.md @@ -0,0 +1,243 @@ +# build + +Build a application + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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: `false` + +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. + +### crossOrigin + +Type: `string` + +The crossorigin attribute to use for generated javascript script tags. One of 'none' | 'anonymous' | 'use-credentials' + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/angular/api-web/builders/dev-server.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/dev-server.md new file mode 100644 index 0000000000..ed4a0bc461 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/dev-server.md @@ -0,0 +1,105 @@ +# dev-server + +Serve a web application + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/angular/api-web/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/package.md new file mode 100644 index 0000000000..fcb94cbf4f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/builders/package.md @@ -0,0 +1,113 @@ +# package + +Package a library + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/10.4.13/angular/api-web/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/schematics/application.md new file mode 100644 index 0000000000..c7954c442c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-web/schematics/application.md @@ -0,0 +1,103 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/10.4.13/angular/api-workspace/builders/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/builders/run-commands.md new file mode 100644 index 0000000000..c10a295449 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/builders/run-commands.md @@ -0,0 +1,219 @@ +# run-commands + +Run any custom commands with Nx + +Builder properties can be configured in angular.json when defining the builder, or when invoking it. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/library.md new file mode 100644 index 0000000000..08cbd36929 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/library.md @@ -0,0 +1,133 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/move.md new file mode 100644 index 0000000000..8f330cc62b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/move.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/remove.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/remove.md new file mode 100644 index 0000000000..c641affde7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/remove.md @@ -0,0 +1,71 @@ +# 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 `angular.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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/run-commands.md new file mode 100644 index 0000000000..aece6f40fe --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/run-commands.md @@ -0,0 +1,67 @@ +# 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 `angular.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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/workspace-schematic.md new file mode 100644 index 0000000000..48d2b6607b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/api-workspace/schematics/workspace-schematic.md @@ -0,0 +1,39 @@ +# workspace-schematic + +Generates a workspace schematic + +## Usage + +```bash +nx generate workspace-schematic ... +``` + +By default, Nx will search for `workspace-schematic` in the default collection provisioned in `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/workspace:workspace-schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g workspace-schematic ... --dry-run +``` + +## Options + +### name + +Type: `string` + +Schematic name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/builders.json b/nx-dev/data-access-documents/src/data/10.4.13/angular/builders.json new file mode 100644 index 0000000000..722846ec08 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/builders.json @@ -0,0 +1,14 @@ +[ + "angular", + "cypress", + "express", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/angular/cli/affected-build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-build.md new file mode 100644 index 0000000000..76dc8d0795 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-build.md @@ -0,0 +1,137 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/angular/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-e2e.md new file mode 100644 index 0000000000..f6a9518562 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-e2e.md @@ -0,0 +1,125 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/angular/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/angular/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-lint.md new file mode 100644 index 0000000000..ebf0491368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-lint.md @@ -0,0 +1,125 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/angular/cli/affected-test.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-test.md new file mode 100644 index 0000000000..663ec95368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected-test.md @@ -0,0 +1,125 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/angular/cli/affected.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected.md new file mode 100644 index 0000000000..874b43a5c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/affected.md @@ -0,0 +1,147 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/angular/cli/build.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/10.4.13/angular/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/e2e.md new file mode 100644 index 0000000000..1fdb16dc1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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 & autmatically 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/data-access-documents/src/data/10.4.13/angular/cli/format-check.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/angular/cli/format-write.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/angular/cli/generate.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/generate.md new file mode 100644 index 0000000000..033fcfd871 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/generate.md @@ -0,0 +1,93 @@ +# generate + +Runs a schematic that generates and/or modifies files based on a schematic from a collection. + +## Usage + +```bash +nx generate +``` + +```bash +nx g +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 schematics in the default collection. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/10.4.13/angular/cli/list.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/list.md new file mode 100644 index 0000000000..09742dbc9b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +List the plugins installed in the current workspace: + +```bash +nx list +``` + +List the schematics and builders 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/migrate.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/angular/cli/print-affected.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/10.4.13/angular/cli/report.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run-many.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run-many.md new file mode 100644 index 0000000000..11f3319105 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run-many.md @@ -0,0 +1,101 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/angular/cli/serve.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/10.4.13/angular/cli/test.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/10.4.13/angular/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/workspace-schematic.md new file mode 100644 index 0000000000..1935090762 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/cli/workspace-schematic.md @@ -0,0 +1,29 @@ +# workspace-schematic + +Runs a workspace schematic from the tools/schematics directory + +## Usage + +```bash +nx workspace-schematic +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### list-schematics + +List the available workspace-schematics + +### name + +The name of your schematic` + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/apollo-angular.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/apollo-angular.md new file mode 100644 index 0000000000..c6818acd7f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/apollo-angular.md @@ -0,0 +1,12 @@ +# Using Apollo GraphQL with Angular 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 an Angular application to consume your GraphQL api + +**Blog Post:** [Using Apollo GraphQL with Angular in an Nx Workspace](https://blog.nrwl.io/using-apollo-graphql-with-angular-in-an-nx-workspace-9ad0155c1914) + +**Repository:** [nx-apollo-angular-example](https://github.com/nrwl/nx-apollo-angular-example) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected.png new file mode 100644 index 0000000000..e1dd4042dd Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected2.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected2.png new file mode 100644 index 0000000000..3d8f870b93 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-affected2.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-and-angular.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-and-angular.md new file mode 100644 index 0000000000..5539ef330d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-and-angular.md @@ -0,0 +1,471 @@ +# Building Angular and React Applications Together With Nx + +Large companies often use multiple frontend frameworks to build their products. One product can be built with Angular, another one with React. These products, even though are built by different teams using different stacks, often share components and utilities. + +Setting this up traditionally is challenging. Companies put a lot of effort in making sure teams can collaborate and use each other's work. Nx drastically simplifies this. + +To show how Nx does it, let's build two applications (one in Angular, and one in React) that will use a library of shared web components. + +## Creating a New Nx Workspace + +Let's start by creating a new Nx workspace. The easiest way to do this is to use npx. + +```bash +npx --ignore-existing create-nx-workspace happynrwl --preset=empty +``` + +## Add Angular Capabilities + +An empty workspace does not have any capabilities to create applications. Add capabilities for Angular development via: + +```bash +ng add @nrwl/angular +``` + +## Creating an Angular Application + +An empty workspace has no application or libraries: nothing to run and nothing to test. Let's add an Angular application into it via: + +```bash +ng g @nrwl/angular:app angularapp +``` + +The result should look like this: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ │ ├── app.components.css +│ │ │ │ ├── app.components.html +│ │ │ │ ├── app.components.spec.ts +│ │ │ │ ├── app.components.ts +│ │ │ │ └── app.module.ts +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ ├── styles.scss +│ │ │ └── test.ts +│ │ ├── jest.conf.js +│ │ ├── tsconfig.app.json +│ │ ├── browserslist +│ │ ├── tsconfig.json +│ │ ├── tsconfig.spec.json +│ │ └── tslint.json +│ └── angularapp-e2e/ +│ ├── src/ +│ │ ├── integrations/ +│ │ │ └── app.spec.ts +│ │ ├── fixtures/ +│ │ ├── plugins/ +│ │ └── support/ +│ ├── cypress.json +│ ├── tsconfig.e2e.json +│ └── tslint.json +├── libs/ +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +The generated `main.ts`, will look as follows: + +```typescript +import { enableProdMode } from '@angular/core'; + +import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; +import { AppModule } from './app/app.module'; + +import { environment } from './environments/environment'; + +if (environment.production) { + enableProdMode(); +} + +platformBrowserDynamic() + .bootstrapModule(AppModule) + .catch((err) => console.error(err)); +``` + +And the template of the generated component will look as follows: + +```html +
+ Welcome to {{title}}! + +
+ +

This is an Angular app built with Nx.

+``` + +## Adding React Capabilities + +Generating a React application is just as easy. First, add capabilities for React development via: + +```bash +ng add @nrwl/react +``` + +## Creating a React Application + +Create a React application via: + +`ng g @nrwl/react:app reactapp` and this is what we will see: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ ├── angularapp-e2e/ +│ ├── reactapp/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ │ ├── app.css +│ │ │ │ ├── app.spec.tsx +│ │ │ │ └── app.tsx +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ ├── styles.scss +│ │ │ └── test.ts +│ │ ├── browserslist +│ │ ├── jest.conf.js +│ │ ├── tsconfig.app.json +│ │ ├── tsconfig.json +│ │ ├── tsconfig.spec.json +│ │ └── tslint.json +│ └── reactapp-e2e/ +│ ├── src/ +│ │ ├── integrations/ +│ │ │ └── app.spec.ts +│ │ ├── fixtures/ +│ │ ├── plugins/ +│ │ └── support/ +│ ├── cypress.json +│ ├── tsconfig.e2e.json +│ └── tslint.json +├── libs/ +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Where `main.ts` looks like this: + +```typescript +import * as React from 'react'; +import * as ReactDOM from 'react-dom'; + +import { App } from './app/app'; + +ReactDOM.render(, document.querySelector('happynrwl-root')); +``` + +and `app.tsx` contains the following component: + +```typescript jsx +import * as React from 'react'; +import { Component } from 'react'; + +import './app.css'; + +export class App extends Component { + render() { + const title = 'reactapp'; + return ( +
+
+

Welcome to {title}!

+ +
+

+ This is a React app built with Nx. +

+
+ ); + } +} +``` + +Nx provides a uniform tool for development the commands used for React development are the same as the commands used to develop Angular applications. + +- `ng serve reactapp` serves the React app +- `ng build reactapp` builds the React app +- `ng test reactapp` tests the React app using Jest +- `ng e2e reactapp-e2e` tests the React app using Cypress + +TypeScript support, Jest, Cypress, source maps, watch mode--all work with React out of the box. If we run ng serve reactapp, we will see the following: + +![serve screenshot](/assets/content/angular/examples/react-serve.png) + +## Creating Shared Components + +Nx makes sharing code between applications easy. What used to take days or even weeks, with Nx takes minutes. Say we want to create a ui library of shared components that we will use in both the React and Angular applications. + +`ng g @nrwl/workspace:lib ui` and this is what we will see: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ ├── angularapp-e2e/ +│ ├── reactapp/ +│ └── reactapp-e2e/ +├── libs/ +│ └── ui +│ ├── src/ +│ │ ├── lib/ +│ │ └── index.ts +│ ├── jest.conf.js +│ ├── tsconfig.lib.json +│ ├── tsconfig.json +│ ├── tsconfig.spec.json +│ └── tslint.json +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Let's create a `greeting.element.ts` in the lib folder: + +```typescript +export class GreetingElement extends HTMLElement { + public static observedAttributes = ['title']; + + attributeChangedCallback() { + this.innerHTML = `

Welcome to ${this.title}!

`; + } +} + +customElements.define('happynrwl-greeting', GreetingElement); +``` + +and reexport it in the `index.ts` file: + +```typescript +export * from './lib/greeting.element'; +``` + +The updated library should look like this + +```treeview +happynrwl/ +├── apps/ +├── libs/ +│ └── ui +│ ├── src/ +│ │ ├── lib/ +│ │ │ └── greeting.element.ts +│ │ └── index.ts +│ ├── jest.conf.js +│ ├── tsconfig.lib.json +│ ├── tsconfig.json +│ ├── tsconfig.spec.json +│ └── tslint.json +├── ... +``` + +## Using the Greeting Element in our Angular App + +### Importing the Library + +Next, let's include the new library. + +```typescript +import '@happynrwl/ui'; // <-- the new library + +import { enableProdMode } from '@angular/core'; + +import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; +import { AppModule } from './app/app.module'; + +import { environment } from './environments/environment'; + +if (environment.production) { + enableProdMode(); +} + +platformBrowserDynamic() + .bootstrapModule(AppModule) + .catch((err) => console.error(err)); +``` + +### Registering CUSTOM_ELEMENTS_SCHEMA + +Next, let's register the `CUSTOM_ELEMENTS_SCHEMA` schema, which will tell the Angular compiler not to error when seeing non-standard element tags in components' templates. + +```typescript +@NgModule({ + declarations: [AppComponent], + imports: [BrowserModule], + providers: [], + schemas: [CUSTOM_ELEMENTS_SCHEMA], + bootstrap: [AppComponent], +}) +export class AppModule {} +``` + +### Using the Greeting Element + +Finally, we can update `app.component.html` to use our shared web component. + +```html +
+ + +
+ +

This is an Angular app built with Nx.

+``` + +## Using the Greeting Element in our React App + +Using Greeting in the react app requires similar steps. + +### Importing Library + +Next, let's include the new library in `main.ts`. + +```typescript jsx +import '@happynrwl/ui'; + +import * as React from 'react'; +import * as ReactDOM from 'react-dom'; + +import { App } from './app/app'; + +ReactDOM.render(, document.querySelector('happynrwl-root')); +``` + +### Adding Intrinsic Types + +Instead of registering `CUSTOM_ELEMENTS_SCHEMA`, let's add `intrinsic.d.ts file`, which serves a similar purpose to `CUSTOM_ELEMENTS_SCHEMA`, next to `main.tsx`. + +```typescript +declare namespace JSX { + interface IntrinsicElements { + [elemName: string]: any; + } +} +``` + +### Using the Greeting Element + +Finally, we can update `app.tsx` to use our shared web component. + +```typescript jsx +import * as React from 'react'; +import { Component } from 'react'; + +import './app.css'; + +export class App extends Component { + render() { + const title = 'reactapp'; + return ( +
+
+ + +
+

+ This is a React app built with Nx. +

+
+ ); + } +} +``` + +## Nx Intelligence + +What we have shown is already quite remarkable. We built two applications in two different framework using a shared library of web components. We can use same commands to serve, build, test the applications. + +But Nx can do a lot more than that. + +If we run `yarn dep-graph`, we will see the following: + +![serve screenshot](/assets/content/angular/examples/react-dep-graph.png) + +Nx understands how our applications and libraries depend on each other. This is extremely important! To really improve the collaboration between teams and make sure that they can use each other's work, the following two things must be true: + +- If the Angular team makes a change to the Angular app itself. Only the Angular app has to be rebuilt and retested. Same is true for the React team. Any tool that requires us to rebuild and retest everything on every PR won't scale beyond a small repository. +- If any of the teams changes the ui library, both the Angular and the React applications should be rebuilt and retested before the PR gets merged into master. This is the only way to guarantee that the PR is safe to merge. + +To see how Nx helps with this, let's commit the changes we have made so far. + +```bash +git add . +git commit -am 'great commit' +``` + +Next, let's create a new branch `git checkout -b angularchange`. In this branch, let's introduce any change to app.component.html and run `yarn affected:dep-graph`. + +![serve screenshot](/assets/content/angular/examples/react-affected.png) + +As you can see, Nx knows that this change only affects the `angularapp` and nothing else. Nx can use this information to rebuild and retest only the angularapp: + +```bash +yarn affected:test # only tests angularapp +yarn affected:build # only builds angularapp +``` + +Now, let's introduce a change to `greeting.element.ts` and run `yarn affected:dep-graph`. + +![serve screenshot](/assets/content/angular/examples/react-affected2.png) + +Both `angularapp` and `reactapp` are affected by this change because they both depend on the greeting component. + +```bash +yarn affected:test # tests ui, angularapp, reactapp +yarn affected:build # only builds angularapp, reactapp +``` + +This is what we just saw: + +- If we only touch our code, we only have to retest and rebuild our code. +- If we touch something that affects other teams, we'll have to rebuild and retest their applications as well. + +Because this is a simple example, the impact is easily deductible. But a real workspace can have a dozen applications and hundred of libraries. Ad-hoc solutions do not work at such scale--we need tools like Nx, that can help us manage those workspaces. + +## Summary + +With Nx, we can build multiple applications using different frontend frameworks in the same workspace. These applications can share components, services, utilities. In this example we looked at a library of web components that we used in Angular and React applications. But we could go further: we could build the shared component using Angular Elements and then use it in the React application. Nx also allows us to build the backend next to our frontend and share code between them. + +Nx analyses the code base to figure out how libraries and applications depend on each other. This analysis happens across frameworks and across client-server boundaries. + +## Example App + +You can find the example application [here](https://github.com/nrwl/nx-angular-and-react). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-dep-graph.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-dep-graph.png new file mode 100644 index 0000000000..81f04e4632 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-dep-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-serve.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-serve.png new file mode 100644 index 0000000000..b73ca2038a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/examples/react-serve.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/create-workspace.gif b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/create-workspace.gif new file mode 100644 index 0000000000..85a97af73b Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/create-workspace.gif differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/dep-graph.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/dep-graph.png new file mode 100644 index 0000000000..0cc9c65cdf Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/dep-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/nx-and-cli.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/nx-and-cli.md new file mode 100644 index 0000000000..da560808b6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/nx-and-cli.md @@ -0,0 +1,81 @@ +# Nx and Angular CLI + +Nx **is not** a replacement for Angular CLI. Under the hood, Nx uses the Angular CLI to generate code and run tasks. + +When you run `nx build myapp`, Nx will invoke `ng build myapp` under the hood. When you run `nx g component mycmp`, Nx will invoke `ng g component mycmp` under the hood. + +When it comes to generating code and running tasks, since `nx` delegates to `ng`, both CLIs will always produce the same result, except that running `nx` will often run a lot faster. + +How? + +Nx CLI uses advanced code analysis and computation caching to reuse previous computation results when possible. The Angular CLI doesn't do it. In other words, use `nx` instead of `ng`: everything will work just the same but often much faster. + +The `Nx CLI` also supports a lot more commands than the Angular CLI. It can run a target against many projects in parallel, run a target against a project and its dependencies, etc.. + +**What does Nx add in addition to being faster?** + +Here are a few tasks that are made possible by Nx. + +## Using effective development practices pioneered at Google + +Using Nx, you can implement monorepo-style development--an approach popularized by Google and used by many tech companies today (Facebook, Uber, Twitter, etc..). + +_Doesn't Angular CLI support having multiple projects in the same workspace?_ + +Yes, starting with Angular CLI 6 you can add different types of projects to a single workspace (by default you can add applications and libraries). This is great, but is not sufficient to enable the monorepo-style development. Nx adds an extra layer of tooling to make this possible. + +### Analyzing and Visualizing the Dependency Graph + +To be able to support the monorepo-style development, the tools must know how different projects in your workspace depend on each other. Nx uses advanced code analysis to build this dependency graph. Run `nx dep-graph` to see the dependency diagram of your workspace. + +![Dependency Diagram](./dep-graph.png) + +### Rebuilding and Retesting What is Affected + +To be productive in a monorepo, you need to be able to check that your change is safe, and rebuilding and retesting everything on every change won’t scale. Nx uses code analysis to determine what needs to be rebuilt and retested. + +```bash +nx affected:build # reruns build for all the projects affected by a PR + +nx affected:test # reruns unit tests for all the projects affected by a PR +``` + +Nx will topologically sort the projects, and will run what it can in parallel. Nx will also use its advanced distributed computation caching to drastically speed up your commands. + +## Full-Stack Development + +With Nx, you can build a backend application next to your frontend application in the same repository. The backend and the frontend can share code. You can connect them to enable a fantastic development experience. + +_How do you do it?_ + +First, generate an Angular application. + +```bash +nx g @nrwl/angular:app frontend +``` + +Second, generate a Nest application. + +```bash +nx g @nrwl/nest:app backend --frontend-project frontend # Generate a Nest Application and sets up a proxy for the frontend application. +``` + +## Use Innovative Tools + +Tools like Cypress, Jest, Prettier, and Nest have gained a lot of popularity. + +Adding these tools to the dev workflow is challenging in a regular Angular CLI project. The choice you have is not between Protractor or Cypress, but between a hacked-up setup for Cypress and a great CLI setup for Protractor. Nx changes that! + +When using Nx, adding Cypress or Jest is easy: + +```bash +nx g @nrwl/angular:app myapp --e2e-test-runner=cypress --unit-test-runner=jest # cypress and jest are actually defaults +nx g @nrwl/angular:app myapp --e2e-test-runner=protractor --unit-test-runner=karma +``` + +Tests can then be run just like you would run them normally: + +```bash +nx test myapp +nx e2e myapp +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/resources.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/resources.md new file mode 100644 index 0000000000..3558206cb4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/resources.md @@ -0,0 +1,126 @@ +# Resources + +## 45-Minute Walkthrough + + + +## Quick Introductions (10 Minutes) + + + +## Nx Console Overview + + + +## Courses + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## Resources + +### Talks + +- [Smarter & Faster Angular Development with Nx (ngconf webinar)](https://youtu.be/LEqJ1xKf_1w), Juri Strumpflohner, Isaac Mann (Oct 16, 2020) + +- [React Development At Scale (React Vancouver Virtual Meetup)](https://youtu.be/ZGXuzVipe1U?t=3721), Jack Hsu (May 27, 2020) + +- [Scalable React Development (React Summit Remote Edition)](https://www.youtube.com/watch?v=Lr-u2ALSEQg), Jason Jean (April 17, 2020) + Slides: [https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/](https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/) + +- [Beyond Basics: Scaling Development across Large Teams (Angular Rome Meetup online)](https://docs.google.com/presentation/d/1zEgeppole9avhrvV6Zmpmk-L1W9-6JsHbnjaJwBigtQ/edit?usp=sharing), Juri Strumpflohner (April 2, 2020) + +- [Develop like Google, Microsoft, and Facebook with Nx - Dev Nexus](https://prezi.com/view/BVhl92reqg7cnhvv6hhH/), Jason Jean (February 18, 2020) + +- [Enhancing the workspace with Custom Builders - AngularToronto](https://www.youtube.com/watch?v=M1Bk_O49n94), Benjamin Cabanes (February 18, 2020) + +- [Advanced Nx - Angular Air](https://www.youtube.com/watch?v=pcTSDMid-aE), Isaac Mann (February 5th, 2020) + +- [Teach Me Anything - HackFlix](https://www.youtube.com/watch?v=WRmj4JwfoMs) - Isaac Mann (January 9th, 2020) + +* [E2E Testing at Half the Cost - NG-BE 2019](https://www.youtube.com/watch?v=C88th0SbepE), Isaac Mann (Dev 10, 2019) + +* [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +* [Building Large Angular Apps - ngBucharest](https://www.youtube.com/watch?v=bKhyTeTCf7M), Isaac Mann (March 30, 2019) + + - Slides: [https://prezi.com/view/jglXvEfeqnjEr4l2L11h/](https://prezi.com/view/jglXvEfeqnjEr4l2L11h/) + +* [Modern Development with Angular CLI & Nrwl Nx](https://www.youtube.com/watch?v=tE8sUAfKI3g), Victor Savkin at ngAtlanta (Feb 5, 2019) + +* [Supercharging the Angular CLI](https://www.youtube.com/watch?v=bMkKz8AedHc) - ngVikings, James Henry (March 10, 2018) + +* [Hands on Full Stack development with Nx and Bazel](https://www.youtube.com/watch?v=1KDDIhcQORM) - ngConf, Alex Eagle, Torgeir Helgevold (April 19, 2018) + +* [Angular at Large Organizations](https://www.youtube.com/watch?v=piQ0EZhtus0) - ngConf, Victor Savkin(April 20, 2018) + +* [Building Large Angular Apps Successfully with Nx - AngularNYC Meetup](https://youtu.be/Jwv3wRZ3BTM), Jason Jean (December 19, 2018) + +- [Nx: The New Way to Build Enterprise Angular Apps](https://www.youtube.com/watch?v=xo-1SDmvM8Y) - Angular Mix, Jeff Cross & Victor Savkin (October 11, 2017) + +### Podcasts and Shows + +- [Nx Plugins - ngHouston](https://youtu.be/bydqr-Yxsu8), Wes Grimes and Jon Cammisuli (April 8 2020) + +- [Apollo GQL, Angular & Nx - ngHouston](https://youtu.be/bydqr-Yxsu8), Philip Fulcher (Feb 26, 2020) + +- [Teach Me Anything - With Isaac Mann from Nrwl](https://youtu.be/WRmj4JwfoMs), Isaac Mann (Jan 9, 2020) + +- [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +- [React Roundup: Nx and Monorepos](https://player.fm/series/react-round-up/rru-081-nx-and-monorepos-with-jeffrey-cross-and-victor-savkin), Victor Savkin (Oct 1, 2019) + +- [Nx and Angular CLI - Adventures in Angular](https://devchat.tv/adv-in-angular/aia-254-nx-and-angular-cli-with-brandon-roberts/), Brandon Roberts (Aug 27th 2019) + +- [ngHouston: NX Demo](https://www.youtube.com/watch?v=E_UlU2Yv4G0) (Dec 7, 2017) + +- [ngAir 140: Nx for Enterprise Angular Development](https://www.youtube.com/watch?v=qYNiOKDno_I), Victor Savkin (Dec 12, 2017) + +### Nx Demo & Tutorial Videos + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (Angular)](https://youtu.be/h5FIGDn5YM0) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Nx Console - A Must-Have Visual Studio Code Extension for Angular Developers](https://youtu.be/IIetmfgozgI) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +### Books amd Blogs + +- [Nx blog posts](https://blog.nrwl.io/nx/home) + +- [Angular Enterprise Monorepo Patterns Book (free)](https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book?utm_campaign=Book%3A%20Monorepo%20Patterns%2C%20Jan%202019&utm_source=Github&utm_medium=Banner%20Ad) + +* [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +* [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +- [Tiny Angular application projects in Nx workspaces](https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/#peer-reviewers--30/) (March 2020) + +### Misc + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [xplat - Cross-platform tools for Nx workspaces](https://nstudio.io/xplat/) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/why-nx.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/why-nx.md new file mode 100644 index 0000000000..57865b754b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/getting-started/why-nx.md @@ -0,0 +1,61 @@ +# Why Nx? + +Nx is the preeminent toolkit for Monorepo development, which helps you to build software smarter and faster. With Nx you can build full-stack applications with your preferred framework, integrate with modern tools you’re probably already using, and reinforce best practices for your entire development team or enterprise. Use Nx to build software at scale, the better way. + +- Out of the box integration with Cypress, Jest, Typescript, Prettier + more +- Has a growing ecosystem, and a community plugin market +- Many leading enterprises are already using Nx to build the software you know and love + +## 10-Minute Nx Overview + + + +## Why Monorepos? + +A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them. + +### What are the benefits of a monorepo? + +- **Shared code** - Keep your code DRY across your entire organization. Reuse validation code, UI components and types across the code base. Reuse code between the backend and the frontend. +- **Atomic changes** - Change a server API and modify the clients that consume that API in the same commit. You can change a button component in a shared library and the applications that use that component in the same commit. This saves the pain of trying to coordinate commits across multiple repositories. +- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe. +- **Single set of dependencies** - Use a single version of third party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3 year old version of a framework library or an old version of webpack. + +## Why Not Code Collocation? + +A naive implementation of a monorepo is simply code collocation - placing all the code from multiple repositories into the same repo without adequate tooling to coordinate everything. What problems arise from code collocation? + +- **Running unnecessary tests** - In order to ensure nothing was broken by a change, all tests in the entire repository need to be run - even code in projects that are unrelated to the actual change. +- **No code boundaries** - A developer from another team can change code in your project, causing bugs or inconsistencies. Or worse, another team can use code that you intended for private use - forcing you to never change that code for fear of breaking their application. +- **Inconsistent tooling** - Each project uses its own set of commands for running tests, building, serving, etc. This makes it very difficult to move from project to project. + +Tools like Lerna and Yarn Workspaces help optimize the installation of node modules, but they **do not** enable Monorepo-style development. In other words, they solve an orthogonal problem and sometimes can be used in combination with Nx. Read more on it [here](https://blog.nrwl.io/why-you-should-switch-from-lerna-to-nx-463bcaf6821). + +## Nx Can Help + +Nx provides tools to give you the benefits of a monorepo without the drawbacks of simple code collocation. + +### Scaling Your Repo + +- **Faster Command Execution** - Builders allow for consistent commands to test, serve, build, lint, etc, each project. [Nx’s affected command]() helps run commands only on code that is affected by the current change. Nx provides local and distributed caching of builder commands so when someone on your team runs a command, everyone else will use their artifacts to speed up their own command executions, often bringing them down from minutes to seconds. This, in combination with support for distributed and incremental builds helps you scale your development to massive applications and repositories. + +### Scaling Your Organization + +- **Controlled Code Sharing** - You can define libraries with specific enforced APIs and put rules in place to define how those libraries can depend on each other. A CODEOWNERS file can be used to restrict who is allowed to change files in each project. +- **Consistent Code Generation** - Schematics allow you to automate code creation and modification tasks. Instead of writing a 7 step guide in a readme file, you can create a schematic to prompt the developer for inputs and then modify the code directly. Nrwl provides plugins which contain useful builders and schematics for a lot of popular tools. Also, there is a growing number of community provided plugins. +- **Accurate Architecture Diagram** - Most architecture diagrams are wrong the moment they are written down. And every diagram becomes out of date as soon as the code changes. Since Nx understands your code, it can generate an up-to-date and accurate diagram of how projects depend on each other. And for cases where dependencies are not explicit in the code, you can manually tell Nx about project dependencies. + +## Next Steps + +**Learn Nx Fundamentals:** + +- [Interactive Nx Tutorial](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) +- [45-Minute Walkthrough on YouTube](https://www.youtube.com/watch?v=h5FIGDn5YM0) + +**Dive Deep:** + +- [Nx CLI](/{{framework}}/cli/overview) +- [Configuration Files](/{{framework}}/workspace/configuration) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/cli-overview.md new file mode 100644 index 0000000000..d92ffe5c1f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/cli-overview.md @@ -0,0 +1,328 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Nx CLI and Angular CLI + +Nx **is not** a replacement for Angular CLI. Under the hood, Nx uses the Angular CLI to generate code and run tasks. + +When you run `nx build myapp`, Nx will invoke `ng build myapp` under the hood. When you run `nx g component mycmp`, Nx will invoke `ng g component mycmp` under the hood. + +When it comes to generating code and running tasks, since `nx` delegates to `ng`, both CLIs will always produce the same result, except that running `nx` will often be a lot faster. + +How? + +Nx CLI uses advanced code analysis and computation caching to reuse previous computation results when possible. The Angular CLI doesn't do it. In other words, use `nx` instead of `ng`: everything will work just the same but often much faster. + +The `Nx CLI` also supports a lot more commands than the Angular CLI. It can run a target against many projects in parallel, run a target against a project and its dependencies, etc.. + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/angular`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called schematics. Schematics provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/angular:application myapp +``` + +The `@nrwl/angular` package contains a collection of schematics, with `application` being the one used in this example. The Nx CLI applies the schematic to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the schematic. + +```sh +nx generate @nrwl/angular:application myapp --style=scss +``` + +You can preview the changes a schematic makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the schematic. + +**Generate command:** + +`nx generate` runs schematics to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[schematic-name] [options]` + Example: `nx generate @nrwl/angular:component mycmp --project=myapp` + +## Running Tasks + +The Nx CLI uses builders to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +A builder is a function that uses the Architect API to perform a complex process such as "build", "test", or "lint". + +You can configure the builders in `angular.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "architect": { + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` builder, and the `test` target uses `@nrwl/jest:jest`. Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # producttion configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any builders you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx affected --target=build --prod +``` + +## 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` +3. `workspaceRoot/.local.env` +4. `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 `.local.env` files for their local environment and override any project defaults set in `.env` + +For example: + +1. `workspaceRoot/apps/my-app/.local.env` 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/.local.env` 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](https://nx.dev/angular/workspace/computation-caching#nx-cloud-and-distributed-computation-memoization)). + +### 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](https://nx.dev/angular/plugins/workspace/builders/run-commands#envfile) builder and execute your command inside of the builder + +## ng add Functionality + +To run the equivalent of the Angular CLI's `ng add` command for a package named `my-package`, you need to run two commands: + +```shell script +# npm +npm i my-package +nx g my-package:ng-add +``` + +```shell script +# yarn +yarn add my-package +nx g my-package:ng-add +``` + +Note: The plugins maintained by Nrwl have `init` as an alias for `ng-add`, so you can run `nx g @nrwl/angular:init` or `nx g @nrwl/angular:ng-add`. + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/configuration.md new file mode 100644 index 0000000000..324f992bab --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/configuration.md @@ -0,0 +1,361 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `angular.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## angular.json + +The `angular.json` configuration file contains information about the targets and schematics. Let's look at the following example: + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "myapp:build", + "proxyConfig": "apps/myapp/proxy.conf.json" + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js", + "tsConfig": "apps/myapp/tsconfig.spec.json" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": { + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/web" + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": {} + } +} +``` + +- `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'. +- `architect` configures all the targets which define what tasks you can run against the library. + +> Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular. + +### Targets + +Let's look at the simple architect target: + +```json +{ + "test": { + "builder": "@nrwl/jest:jest", + "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 run mylib:mytest`. + +**Builder** + +The `builder` 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 builder named `jest` and invoke it with the options. + +**Options** + +The `options` provides a map of values that will be passed to the builder. 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 builder: + +```json +{ + "jestConfig": "libs/mylib/another-jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" +} +``` + +**Outputs** + +The `outputs` property lists the folders the builder will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + } +} +``` + +You can select a configuration like this: `nx build myapp --configuration=production` or `nx run myapp:build:configuration=production`. + +The following show how the builder options get constructed: + +```bash +require(`@nrwl/jest`).builders['jest']({...options, ...selectedConfiguration, ...commandLineArgs}}) // Pseudocode +``` + +The selected configuration adds/overrides the default options, and the provided command line args add/override the configuration options. + +### Schematics + +You can configure default schematic options in `angular.json` as well. For instance, the following will tell Nx to always pass `--style=scss` when creating new libraries. + +```json +{ + "schematics": { + "@nrwl/angular:library": { + "style": "scss" + } + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/angular:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/angular" + } +} +``` + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "angular.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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. + +### 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 dependencies between shared files and projects cannot be inferred statically. You can configure those using `implicitDependencies`. + +```json +{ + "implicitDependencies": { + "angular.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": { + "mypackage": ["mylib"] + }, + "scripts": { + "check:*": "*" + } + }, + "globalFile": ["myapp"], + "styles/**/*.css": ["myapp"] + } +} +``` + +In the example above: + +- Changing `angular.json` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +## .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 will not be taken into account in the `affected` calculations. +2. Even if the file is outside an app or library, `nx workspace-lint` will not warn about it. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-data-persistence.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-data-persistence.md new file mode 100644 index 0000000000..d5f0bdd266 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-data-persistence.md @@ -0,0 +1,216 @@ +# 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/data-access-documents/src/data/10.4.13/angular/guides/misc-ngrx.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-ngrx.md new file mode 100644 index 0000000000..784b1e43fa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-ngrx.md @@ -0,0 +1,119 @@ +# 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](/{{framework}}/plugins_angular_schematics/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/data-access-documents/src/data/10.4.13/angular/guides/misc-upgrade.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-upgrade.md new file mode 100644 index 0000000000..b840a29028 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/misc-upgrade.md @@ -0,0 +1,99 @@ +# Upgrading AngularJS Applications + +There are two main ways to incrementally upgrade your AngularJS application: using UpgradeModule and using downgradeModule. Nx helps you use both. + +## Using UpgradeModule + +NgUpgrade is a library put together by the Angular team, which we can use in our application to mix and match AngularJS and Angular components and bridge the AngularJS and Angular dependency injection systems. We can call such an application a “hybrid application”, and the code required to bootstrap it an "upgrade module". + +Setting up an Upgrade Module manually involves several steps and is easy to misconfigure. **Nx** provides a command that does it for you. + +```console +ng g @nrwl/angular:upgrade-module legacyApp --project=myapp +``` + +This will add and set up `UpgradeModule`, configure `legacyApp`, and will add all the needed dependencies to `package.json`. + +Open the generated `legacy-app-setup.ts` and you will find all the code needed to bridge the AngularJS and Angular applications. + +### Testing Hybrid Applications + +For a lot of applications, just running one command is sufficient to convert your application into a hybrid application. That's not always the case--sometimes changes are required. To make this iterative process easier, Nx creates `hybrid.spec.ts`, which you can use to make sure the upgrade module works. + +### After Upgrade Module + +Nx sets up the upgrade module for you to help you get started with your upgrade process. To learn more on how to upgrade your application, once an upgrade module is set up, check out the following resources: + +#### Talk: Upgrading Enterprise Angular Applications + +In this talk at NgConf, Victor Savkin shows how to upgrade your application gradually, component by component, module by module using NgUpgrade and the Angular Router. He discusses the common problems developers face during such migrations and the patterns that can be used to remedy them. + +Embedded content: https://www.youtube.com/embed/izpqQpD8RQ0 + +#### Blog: Upgrading Angular Applications + +In this blog post series Victor Savkin covers similar topics but more in depth. He dives deep into NgUpgrade, including the mental model, implementation, subtleties of the API. Then he talks about different strategies for upgrading large AngularJS applications. + +- [NgUpgrade in Depth](https://blog.nrwl.io/ngupgrade-in-depth-436a52298a00) +- [Upgrade Shell](https://blog.nrwl.io/upgrading-angular-applications-upgrade-shell-4d4f4a7e7f7b) +- [Two Approaches to Upgrading Angular Applications](https://blog.nrwl.io/two-approaches-to-upgrading-angular-apps-6350b33384e3) +- [Managing Routers and URL](https://blog.nrwl.io/upgrading-angular-applications-managing-routers-and-url-ca5588290aaa) +- [Using NgUpgrade like a Pro: Lazy Loading AngularJS Applications](https://blog.nrwl.io/using-ngupgrade-like-a-pro-lazy-loading-angularjs-applications-469819f5c86) + +## Using downgradeModule + +While NgUpgrade provides a way to run Angular and AngularJS code side by side and bridge the dependency injection systems, it does take a bit of a performance hit. Reason being, you end up having both change detection systems running at the same time regardless of if you are hitting Angular or AngularJS code. + +The Angular upgrade package provides a way to do "NgUpgrade Lite", which is the concept of running AngularJS and downgrading Angular to run when needed, as well as keeping the change detection systems separate. Angular change detection will only run on Angular code and AngularJS scope digest will only run on AngularJS code. + +For finer grain control over application performance during conversion to Angular, the downgrade module approach is a good choice. + +Setting up a Downgrade Module manually involves several steps and is easy to misconfigure. **Nx** provides a command that does it for you. + +```console +ng @nrwl/angular:downgrade-module legacyApp --project=myapp +``` + +This will configure the `AppModule` to not bootstrap the `AppComponent` and instead set it up as an entry component. It will also configure `main.ts` to bootstrap AngularJS and use the `downgradeModule` to downgrade the Angular `AppModule` to run in AngularJS. + +Open `main.ts` and you will find all the code needed to run AngularJS and include Angular code. + +### After Downgrade Module + +Nx sets up the downgrade module for you to help you get started with your conversion process to Angular. Check out the blog post on [Using Nrwl/Nx to Upgrade You AngularJS Applications to Angular](https://blog.nrwl.io/using-nrwl-nx-to-upgrade-you-angularjs-applications-to-angular-f5b8adf188aa) to learn more about the differences between Upgrade and Downgrade Module. + +From there, a good next step is to pick a slicing strategy for taking on incremental upgrades. To learn about the vertical and horizontal slicing strategies check out [Two Approaches to Upgrading Angular Applications](https://blog.nrwl.io/two-approaches-to-upgrading-angular-apps-6350b33384e3). + +#### Upgrading/Downgrading Injectables and Components + +Once you have decided on a slicing strategy you will move forward with converting AngularJS components (directives) and injectables to Angular and downgrading them to use them in the AngularJS bits as well as upgrading some of the AngularJS bits to be able to run in the Angular ones. The blog post [NgUpgrade in Depth](https://blog.nrwl.io/ngupgrade-in-depth-436a52298a00) includes information on handling injectable and component conversions to Angular, which are the same way to do it for the Downgrade Module approach. Take a look at the sections on **Dependency Injection** and **Component Integration** to learn how to upgrade/downgrade injectables and components for use in AngularJS and Angular. + +#### Controlling Change Detection + +The other piece of the puzzle that you will need to handle is manually triggering change detection if your component tree consists of a combination of AngularJS and Angular components. + +If you have an Angular component that has an AngularJS child component you may need to inject in `$rootScope` and call `$digest` after your Angular component does something to get the child AngularJS component to update: + +```typescript +@Component({ + selector: 'app-ticket-list', + templateUrl: './ticket-list.component.html', + styleUrls: ['./ticket-list.component.css'], +}) +export class TicketListComponent implements OnInit { + @Input() tuskTickets; + notifyList = []; + + constructor(@Inject('$rootScope') private rootScope: any) {} + + onNotifyAll() { + this.notifyList = this.tuskTickets.map(function (t) { + return t.id; + }); + // we need to force digest to trigger angularjs change detection + this.rootScope.$digest(); + } +} +``` + +Since the two change detection systems are kept separate in the Downgrade Module approach, you have to handle telling the other to run if the one you are in needs to affect the other. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/karma-to-jest.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/karma-to-jest.md new file mode 100644 index 0000000000..b0eb35a618 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/karma-to-jest.md @@ -0,0 +1,102 @@ +# Migrating from Karma to Jest + +By default, the Angular CLI provides Karma as a test runner and Jasmine as the test framework. Nx offers the choice of using Jest for both runner and framework. If a library in your Angular workspace was created to use Karma, there are three steps to migrate to Jest: + +## 1. Add Jest support to the workspace + +The following command adds Jest support to the workspace. This only needs to be performed once per workspace. You can skip this step if Jest is already added to the workspace. + +```bash +ng generate jest +``` + +## 2. Replace Karma config with Jest config files for a lib + +Assuming we have the default configuration produced by the Angular CLI, we need to perform the following operations: + +**Step 1** + +Delete `karma.conf.js` from the lib's folder. If you have custom code or options here you will need to make a copy so that you can try to recreate this behavior with Jest in `src/jest.config.js` after step 4. + +**Step 2** + +Delete `src/test.ts`. Again if you have custom code in here you will need to make a copy and recreate the behavior after Step 4 in the `src/lib/test-setup.ts`. + +**Step 3** + +Remove the test section for the project in your `angular.json` or `workspace.json`: + +```json +: { + "architect": { + "test": { + "builder": "@angular-devkit/build-angular:karma", + "options": { + "main": "libs/shared/view-component/src/test.ts", + "tsConfig": "libs/shared/view-component/tsconfig.spec.json", + "karmaConfig": "libs/shared/view-component/karma.conf.js" + } + } + } +} +``` + +**Step 4** + +```bash +ng generate jest-project --project +``` + +Any custom code that was present in Step 1 and 2 should be recreated now in the new Jest config files that were generated by this command. + +**Step 5** + +Modify `tsconfig.spec.ts` in the lib’s folder and add Jest typings: add jest under types and remove previous framework (e.g. jasmine) + +```bash +"types": [ "jest", "node" ] +``` + +## 3. Migrate spec files to Jest + +This step is very manual and varies widely based on the usage of features from various frameworks. Below are some common migrations for Jasmine. Jest’s API is very close to Jasmine’s but there are some differences. + +**Spies** + +- Bare spies + - Jasmine + ```ts + const myMock = jasmine.createSpy('myMock); + ``` + - Jest + ```ts + const myMock = jest.fn(); + ``` +- Spies on existing objects + - Jasmine + ```ts + spyOn(foo, 'setBar'); + ``` + - Jest + ```ts + jest.spyOn(foo, ‘setBar’); + ``` + +It’s a good practice to avoid relying on `spyOn` being global and instead using `jest.spyOn`. The behavior of the Jest spies is different from the Jasmine spies in the following ways: + +- The method being spied on is called by default in Jest, similar to Jasmine’s `spyOn(foo, ‘setBar’).and.callThrough();` To avoid calling through to the original function, set the `mockImplementation` to override it: `jest.spyOn(foo, ‘setBar’).mockImplementation(() => {})`. This is similar to Jasmine’s `spyOn(foo, ‘setBar’).and.callFake` +- Jasmine’s `spyOn(foo, "getBar").and.returnValue(745);` would become `jest.spyOn(foo, ‘setBar’).mockImplementation(() => 745)` in Jest + +It is worth looking at the documentation for Jasmine (or your previous test framework) and compare against the Jest documentation - most functionality should be supported but some code changes might be needed. + +**Marbles: `hot` and `cold`** + +`@nrwl/nx/testing` exports `hot` and `cold` from `jasmine-marbles`. We now need to import these from `jest-marbles` instead. + +At this point, the spec files might have issues that need to be fixed before tests can be run: the linter will highlight these issues. + +Once the spec files have been fixed we can run the tests (using Jest): + +```bash +ng test +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/protractor-to-cypress.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/protractor-to-cypress.md new file mode 100644 index 0000000000..6e7b179a52 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/modern-angular/protractor-to-cypress.md @@ -0,0 +1,42 @@ +# Migrating from Protractor to Cypress + +Nx helps configure your e2e tests for you. When running the Nx schematic to create a new app, you can choose Protractor as an option, but the default is Cypress. If you have an existing set of e2e tests using Protractor and would like to switch to using Cypress, you can follow these steps. + +Let's say your existing app is named `my-awesome-app` and the e2e Protractor tests are located in `my-awesome-app-e2e`. + +0. Before you start, make sure you have a clean git working tree (by committing or stashing any in progress changes) +1. Create a throw away app named `delete-this-app` using `Cypress` for the e2e setting. + ```bash + nx g @nrwl/angular:application --name=delete-this-app --e2eTestRunner=cypress + ``` +2. Rename `apps/my-awesome-app-e2e/src` to `apps/my-awesome-app-e2e/src-protractor` + ```bash + mv apps/my-awesome-app-e2e/src apps/my-awesome-app-e2e/src-protractor + ``` +3. Move the contents of `apps/delete-this-app-e2e` to `apps/my-awesome-app-e2e` + ```bash + mv apps/delete-this-app-e2e/* apps/my-awesome-app-e2e + ``` +4. In the `angular.json` (or `workspace.json`) file copy the `e2e` target configuration for `delete-this-app-e2e` and use that to replace the `e2e` target configuration for `my-awesome-app-e2e`. In the new configuration section, replace any instance of `delete-this-app` with `my-awesome-app`. +5. Delete `delete-this-app` and `delete-this-app-e2e` + ```bash + nx g rm delete-this-app-e2e + nx g rm delete-this-app + ``` +6. Edit `apps/my-awesome-app-e2e/cypress.json` and replace any instance of `delete-this-app` with `my-awesome-app`. +7. Delete `apps/my-awesome-app-e2e/protractor.conf.js` + ```bash + rm apps/my-awesome-app-e2e/protractor.conf.js + ``` +8. Migrate your `*.po.ts` files to use the Cypress API as opposed to the Protractor API. + + - The canonical way for Cypress to handle page objects is to create small reusable functions that use the `cy` object to return a reference to whatever element you want to interact with. + +9. Migrate your Protractor `*.spec.ts` files to Cypress `*.spec.ts` files. + + - Refer to the excellent [Cypress docs](https://docs.cypress.io/) for more information. + +10. Run your Cypress tests with the same command that launched your Protractor tests. + ```bash + nx e2e my-awesome-app-e2e + ``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/nx7-to-nx8.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/nx7-to-nx8.md new file mode 100644 index 0000000000..3e90951609 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/nx7-to-nx8.md @@ -0,0 +1,110 @@ +# Nx 7 => Nx 8 + +If you have used Nx since before version 8, things might seem different now. Prior to Nx 8 our packages were `@nrwl/schematics` and `@nrwl/builders`. These packages were organized by which Angular CLI feature they depended on. `@nrwl/schematics` contained the core of Nx + schematics for all of our features: Angular, React, Node, and Nest. This organization had very little meaning to users and made it impossible to install only capabilities needed for Angular. To solve this, in Nx 8, we have organized our packages by feature. + +## Upgrading from Nx 7 to Nx 8 + +To upgrade from a Nx 7 workspace to a Nx 8 workspace, run: + +- `ng update @nrwl/schematics@8.4.8` to update the workspace to the Nx 8 format. +- Commit the results +- `ng update @nrwl/workspace@8.4.8` to update the workspace to 8.4.8. + +### Potential Issues + +- If you use publishable libraries, running `ng update @nrwl/schematics@8.4.8` will incorrectly update the version of `@angular/compiler-cli` and `@angular/language-service`. Update the versions manually before committing the changes. The issue is due to an incorrect peer dependency in `ng-packagr`, which we cannot fix in Nx. +- The schematics section of `angular.json` might still contain references to `@nrwl/schematics`. Update them to point to appropriate package (e.g., `@nrwl/angular`, `@nrwl/react`, `@nrwl/nest`). + +## Where you can find familiar features + +Below is a guide for users to find where the familiar features from Nx 7 can be found in Nx 8. + +### `create-nx-workspace` + +`create-nx-workspace` has not moved and remains in the `create-nx-workspace` package. + +### The Nx CLI + +The `nx` CLI has been moved to `@nrwl/workspace` which contains most of the core of Nx. It is still called `nx` so it can still be found at `./node_modules/.bin/nx`. + +#### `affected`, `format`, `lint`, `dep-graph` + +All CLI commands, `affected`, `format`, `lint`, and `dep-graph` have been moved to `@nrwl/workspace` as well. These commands are still run the same way via `yarn affected`, `yarn format`, etc.. + +### Jest Builder + +The builder for running Jest tests has been moved to `@nrwl/jest` which contains all of the Jest capabilities and can be specified as follows: + +- `@nrwl/builders:jest` is now `@nrwl/jest:jest` + +### Cypress Builder + +The builder for running Cypress tests has been moved `@nrwl/cypress` which contains all of the Cypress capabilities and can be specified as follows: + +- `@nrwl/builders:cypress` is now `@nrwl/cypress:cypress` + +### Angular + +#### Schematics + +All Angular schematics such as `app`, `lib`, `ngrx`, `downgrade-module`, and `upgrade-module` have been moved to `@nrwl/angular` which contains all of the Angular Capabilities. You can generate these same schematics by specifying `@nrwl/angular` as the collection. For example, use `ng g @nrwl/angular:app` to generate an Angular application. If `@nrwl/angular` is the default collection in the workspace, you can continue using `ng g app`. + +#### DataPersistence + +DataPersistence has been moved to `@nrwl/angular` as well and can be imported from `@nrwl/angular`. + +### React + +#### Schematics + +All React schematics such as `app` and `lib` have been moved to `@nrwl/react` which contains all of the React capabilities. You can generate these same schematics by specifying `@nrwl/react` as the collection. For example, use `ng g @nrwl/react:app` to generate a React application. If `@nrwl/react` is the default collection in the workspace, you can continue to use `ng g app`. + +#### Builders + +The builders for building and serving React apps has been moved to `@nrwl/web`. The React builder is no different from the one used to bundle normal web applications so `@nrwl/react` depends on that functionality from `@nrwl/web`. You do not need to add `@nrwl/web` yourself as adding `@nrwl/react` will add it's dependencies for you. + +### Web + +#### Schematics + +All Web schematics such as `app` and `lib` have been moved to `@nrwl/web` which contains all of the Web capabilities. You can generate these same schematics by specifying `@nrwl/web` as the collection. For example, use `ng g @nrwl/web:app` to generate a Web application. If `@nrwl/web` is the default collection in the workspace, you can continue to use `ng g app`. + +#### Builders + +The builders for building and serving Web apps has been moved to `@nrwl/web` and can be specified as follows: + +- `@nrwl/builders:web-build` is now `@nrwl/web:build` +- `@nrwl/builders:web-dev-server` is now `@nrwl/web:dev-server` + +### Nest + +#### Schematics + +All Nest schematics such as `app` have been moved to `@nrwl/nest` which contains all of the Nest capabilities. You can generate these same schematics by specifying `@nrwl/nest` as the collection. For example, use `ng g @nrwl/nest:app` to generate a Nest application. If `@nrwl/nest` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builders for building and serving Nest apps has been moved to `@nrwl/node`. The Nest builder is no different from the one used to bundle normal NodeJS applications so `@nrwl/nest` depends on that functionality from `@nrwl/node`. You do not need to add `@nrwl/node` yourself as adding `@nrwl/nest` will add it's dependencies for you. + +### Express + +#### Schematics + +All Express schematics such as `app` have been moved to `@nrwl/express` which contains all of the Express capabilities. You can generate these same schematics by specifying `@nrwl/express` as the collection. For example, use `ng g @nrwl/express:app` to generate an Express application. If `@nrwl/express` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builders for building and serving Express apps has been moved to `@nrwl/node`. The Express builder is no different from the one used to build normal NodeJS applications so `@nrwl/express` depends on that functionality from `@nrwl/node`. You do not need to add `@nrwl/node` yourself as adding `@nrwl/express` will add it's dependencies for you. + +### Node + +#### Schematics + +All Node schematics such as `app` have been moved to `@nrwl/node` which contains all of the Node capabilities. You can generate these same schematics by specifying `@nrwl/node` as the collection. For example, use `ng g @nrwl/node:app` to generate a Node application. If `@nrwl/node` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builder for building and serving Node apps has been moved to `@nrwl/node` and can be specified as follows: + +- `@nrwl/builders:node-build` is now `@nrwl/node:build` +- `@nrwl/builders:node-execute` is now `@nrwl/node:execute` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/running-custom-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/running-custom-commands.md new file mode 100644 index 0000000000..2afa6f9867 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/running-custom-commands.md @@ -0,0 +1,58 @@ +# Running Custom Commands + +[Compodoc](https://compodoc.app/) is a great tool for automatically generating documentation for Angular projects. In order to use it, you need to run a simple command in the terminal. + +This recipe will show how to run any terminal command within the nx build-chain using Compodoc as an example. + +## Steps + +##### 1. Define the terminal command to be run + +The command we want to run for each project is: + +```bash +compodoc -p [path/to/tsconfig.json] +``` + +##### 2. Update `angular.json` + +For each project for which you want to enable compodoc, add a target in `angular.json`: + +```json +// ... +"my-app": { + "architect": { + "compodoc": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx compodoc -p apps/my-app/tsconfig.app.json" + } + ] + } + } + // ... + } +} +``` + +For more information, see the [run-commands api doc](/{{framework}}/plugins_workspace_builders/run-commands). + +Note: Replace `apps/my-app/tsconfig.app.json` with the appropriate `tsconfig.json` path for each project. + +##### 3. Trigger the builder from the terminal + +To run the builder for a single project: + +```bash +nx run my-app:compodoc +``` + +To run the builder for all affected projects: + +```bash +nx affected --target=compodoc +``` + +For more information, see the [nx affected](/{{framework}}/cli/affected). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/storybook-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/storybook-plugin.md new file mode 100644 index 0000000000..19ad7dcfe7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/storybook-plugin.md @@ -0,0 +1,342 @@ +# Storybook + +![Storybook logo](/shared/storybook-logo.png) + +Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. + +## How to Use Storybook in an Nx Repo + +### Add the Storybook plugin + +```bash +yarn add --dev @nrwl/storybook +``` + +### Generating Storybook Configuration + +You can generate Storybook configuration for an individual project with this command: + +```bash +nx g @nrwl/angular:storybook-configuration project-name +``` + +If there's no `.storybook` folder at the root of the workspace, one is created. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── apps/ +├── libs/ +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +Also, a project-specific `.storybook` folder is added in the root of the project. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── src/ +├── README.md +├── tsconfig.json +└── etc... +``` + +### Running Storybook + +Serve Storybook using this command: + +```bash +nx run project-name:storybook +``` + +### Auto-generate Stories + +The `@nrwl/angular:storybook-configuration` schematic has the option to automatically generate `*.stories.ts` files for each component declared in the library. + +```treeview +/ +├── my.component.ts +└── my.component.stories.ts +``` + +### Run Cypress Tests Against a Storybook Instance + +Both `storybook-configuration` schematic gives the option to set up an e2e Cypress app that is configured to run against the project's Storybook instance. + +To launch Storybook and run the Cypress tests against the iframe inside of Storybook: + +```bash +nx run project-name-e2e:e2e +``` + +The url that Cypress points to should look like this: + +`'/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default'` + +- `buttoncomponent` is a lowercase version of the `Title` in the `*.stories.ts` file. +- `primary` is the name of an individual story. +- `knob-style=default` sets the `style` knob to a value of `default`. + +Changing knobs in the url query parameters allows your Cypress tests to test different configurations of your component. + +### Example Files + +**\*.component.stories.ts file** + +```ts +import { text, number } from '@storybook/addon-knobs'; +import { ButtonComponent } from './button.component'; + +export default { + title: 'ButtonComponent', +}; + +export const primary = () => ({ + moduleMetadata: { + imports: [], + }, + component: ButtonComponent, + props: { + text: text('text', 'Click me!'), + padding: number('padding', 0), + style: text('style', 'default'), + }, +}); +``` + +**Cypress \*.spec.ts file** + +```ts +describe('shared-ui', () => { + beforeEach(() => + cy.visit( + '/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default' + ) + ); + + it('should render the component', () => { + cy.get('storybook-trial-button').should('exist'); + }); +}); +``` + +### Using Addons + +To register an [addon](https://storybook.js.org/addons/) for all storybook instances in your workspace: + +1. In `/.storybook/main.js`, in the `addons` array of the `module.exports` object, add the new addon: + ``` + module.exports = { + stories: [...], + ..., + addons: [..., '@storybook/addon-knobs/register'], + }; + ``` +2. If a decorator is required, in each project's `/.storybook/preview.js` use the `addDecorator` function. + + ``` + import { configure, addDecorator } from '@storybook/angular'; + import { withKnobs } from '@storybook/addon-knobs'; + + addDecorator(withKnobs); + ``` + +**-- OR --** + +To register an [addon](https://storybook.js.org/addons/) for a single storybook instance, go to that project's `.storybook` folder: + +1. In `main.js`, in the `addons` array of the `module.exports` object, add the new addon: + ``` + module.exports = { + stories: [...], + ..., + addons: [..., '@storybook/addon-knobs/register'], + }; + ``` +2. If a decorator is required, in `preview.js` use the `addDecorator` function. + + ``` + import { configure, addDecorator } from '@storybook/angular'; + import { withKnobs } from '@storybook/addon-knobs'; + + addDecorator(withKnobs); + ``` + +### More Information + +For more on using Storybook, see the [official Storybook documentation](https://storybook.js.org/docs/basics/introduction/). + +## Upgrading to Storybook 6 (and Nx versions >10.1.x) + +Nx now comes with [Storybook version 6](https://storybook.js.org/releases/6.0). Chances are, if you used Nx version `10.1.x` or older with Storybook, you are using [Storybook version 5.3](https://storybook.js.org/releases/5.3) with configuration files of [Storybook version 5.2](https://storybook.js.org/releases/5.2). + +Nx version `10.2.x` will continue to support Storybook version `5.2.x`, however newer versions of Nx will only support Storybook version `6` (and on). + +We chose not to provide an automatic migration script for your Storybook instances and configurations across your apps and libraries, since there a number of breaking changes that Storybook introduced in versions `5.3` and `6.0`, and making decisions on what to migrate automatically would risk the integrity of your code. Instead, when you choose to migrate from Nx versions `<10.1.x` to Nx versions `>10.2.x` we will keep your Storybook packages and Storybook instances and configurations intact. We suggest that you do the migration on your own, manually, using the guide below, with all the references to the official Storybook migration guides. Look at the use cases below, and follow the one that matches your case. + +### Use cases: + +#### Use case 1: Create an Nx workspace from scratch using the latest version of Nx + +If you are creating an Nx workspace using the latest version of Nx, the latest version of Storybook (version 6) will be used as well. You do not need to do anything. + +#### Use case 2: I already have an Nx workspace that does NOT use Storybook and I want to migrate to the latest Nx + +If you already have an Nx workspace with a previous version of Nx that does NOT use Storybook, and you migrate to the latest Nx using the migrate scripts provided by Nx, and then, after the migration to the latest Nx, you choose to add Storybook, the latest version of Storybook will be used. You do not need to do anything. + +#### Use case 3: I already have an Nx workspace with Storybook and I want to migrate to the latest Nx + +In that case, when you run the Nx migration scripts, the scripts will ignore the Storybook packages, the Storybook configuration files, the Storybook instances in your apps and libraries, and all the generated stories. If you continue to add Storybook configurations and Storybook instances to new libraries and applications, then the version of Storybook that you already have will be used (most probably, if you have not changed anything manually, that version will be `5.3.9` using, however, the configuration files of `5.2`). You will have to do the [upgrade to the latest Storybook on your own, manually](#upgrading-to-storybook-6-manually). After that, Nx will use that version, and configure all new Storybook instances using the new version. + +### Upgrading to Storybook 6 manually + +#### Step 0: + +**Commit any changes you have locally**. We would suggest that you start the migration with a clean git history, in case anything goes wrong. + +#### Step 1: Changing the configuration files from version 5.2 to 5.3 + +The most noticeable change in Storybook versions newer than `5.2` is that the configuration files have changed names and content. +Quoting from the [official Storybook migration guide](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-52x-to-53x): + +- `presets.js` has been renamed to `main.js`. `main.js` is the main point of configuration for storybook. +- `config.js` has been renamed to `preview.js`. `preview.js` configures the "preview" iframe that renders your components. +- `addons.js` has been renamed to `manager.js`. `manager.js` configures Storybook's "manager" UI that wraps the preview, and also configures addons panel. + +Please follow the [official Storybook version 5.2.x to 5.3.x migration guide](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-52x-to-53x) to change your files accordingly. + +If you are using Storybook using only the generated files after running the `storybook-configuration` schematic, things might be easier for you. Please check the [sample files for a manual upgrade](#sample-files-for-manual-upgrade). + +#### Step 2: Going from version 5.3 to 6.0 + +Please check out this official [Storybook 6 Migration Guide](https://medium.com/storybookjs/storybook-6-migration-guide-200346241bb5) article, as well as the [detailed guides here](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-53x-to-60x). + +- One big change in Storybook version `6` is that it has **built-in Typescript support**. This means that you can remove Typescript configurations from your configuration files. +- Please also **check that your stories match any differences in syntax** introduced in versions `5.3` and `6.0`. + +#### Step 3: Upgrade all `@storybook/*` packages in your project + +Check your `package.json` file for all `@storybook` packages. Install the latest versions of these, usign `yarn`: + +For example: + +``` +yarn add --dev @storybook/angular@latest +``` + +#### Step 4: Check that everything works as expected + +Check that everything works as expected. If you are still having trouble, you can submit you issue in the [GitHub Nx repo](https://github.com/nrwl/nx). We wish you luck! + +### Sample files for manual upgrade + +If you have not changed the content of the files which the `storybook-configuration` schematic produced, you can use the following samples to migrate to Storybook `6`: + +#### Configuring the root `./storybook` directory + +- In the root `./storybook` directory, create a new file named `main.js` with the following content: + +``` +module.exports = { + stories: [], + addons: ['@storybook/addon-knobs/register'], +}; +``` + +- If you have any addons in the `addons.js` file, add them in the `addons` array in the `main.js` file. If you are using the default generated files without any changes, you should only have the `@storybook/addon-knobs/register` addon, which we already put in the array. You can now delete the `addons.js` file. + +- The other two files remain unchanged. + +#### Configuring the Storybook instances across apps and libraries - the library-specific `./storybook` directories + +- In the library `./storybook` directory, create a new file named `main.js` with the following content: + +``` +const lib_main_module = require('../../.storybook/main'); + +lib_main_module.stories.push('../src/lib/**/*.stories.mdx'); +lib_main_module.stories.push('../src/lib/**/*.stories.@(js|jsx|ts|tsx)'); +module.exports = lib_main_module; +``` + +Please take extra care making sure that the path to the root `./storybook` directory provided in the first line is correct. + +- If you have any addons in the `addons.js` file, add them in the `addons` array in the `main.js` file. You can add any addons in the `addons` module array using the following syntax: + +``` +lib_main_module.addons.push(''); +``` + +After you add any addons in the `main.js` file, you can safely delete the `addons.js` file. If you are using the default generated files without any changes, your `addons.js` file should be empty (but an import line, referencing the root `addons.js` file). + +- Rename the file `config.js` to `preview.js` and remove the last line where your stories paths are configured. Now, the contents of the `preview.js` file will look like this: + +``` +import { addDecorator } from '<%= uiFramework %>'; +import { withKnobs } from '@storybook/addon-knobs'; + +addDecorator(withKnobs); +``` + +- Modify the contents of `webpack.config.js`. Remove the following lines, which are the TypeScript configuration, which is not needed by Storybook any more: + +``` + config.resolve.extensions.push('.ts', '.tsx'); + config.module.rules.push({ + test: /\.(ts|tsx)$/, + loader: require.resolve('babel-loader'), + options: { + presets: [ + '@babel/preset-env', + '@babel/preset-react', + '@babel/preset-typescript' + ] + } + }); +``` + +#### Check final folder structure + +Your folder structure should now look like this: + +``` +/ +├── .storybook/ +│ ├── main.js +│ ├── tsconfig.json +│ └── webpack.config.js +├── apps/ +├── libs/ +│ └── / +│ ├── .storybook/ +│ │ ├── main.js +│ │ ├── tsconfig.json +│ │ └── webpack.config.js +│ ├── src/ +│ ├── README.md +│ ├── tsconfig.json +│ └── etc... +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +### Storybook v6 args and controls + +Storybook v6 moves from "knobs" to args and controls when it comes to defining and manipulating your storybook +component properties. Feel free to use the new args way of defining stories. More can be found +[on the official Storybook docs](https://storybook.js.org/docs/angular/writing-stories/args). + +> **Note:** Nx does not yet automatically generate stories that use the args syntax. The main reason is that args don't +> yet support being loaded via the iframe URL which is used in Nx to setup your Storybook based e2e tests. Once support +> is present in Storybook v6, we will provide a way to generate args & controls based stories. More on the progress [here](https://github.com/storybookjs/storybook/issues/12291). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/update.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/update.md new file mode 100644 index 0000000000..4e4723273c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/guides/update.md @@ -0,0 +1,83 @@ +# Updating Nx + +Nx provides migrations which help you stay up to date with the latest version of Nx. + +Not only do we migrate the version of Nx, but we also update the versions of dependencies which we install such as jest and cypress. + +We recommend waiting for Nx to update these dependencies for you as we verify that these versions work together. + +## How to Migrate + +### Generate migrations.json + +All you you have to do to update Nx to the latest version is run the following: + +```bash +nx migrate @nrwl/workspace +nx migrate @nrwl/workspace@version # you can also specify version +``` + +This will fetch the specified version of `@nrwl/workspace`, analyze the dependencies and fetch all the dependent packages. The process will keep going until the whole tree of dependencies is resolved. This will result in: + +- `package.json` being updated +- `migrations.json` being generated + +At this point, no packages have been installed, and no other files have been touched. + +Now, you can inspect `package.json` to see if the changes make sense and install the packages by running `npm install` or `yarn`. + +### Run Migrations + +`migrations.json` contains the transformations that must run to prepare the workspace to the newly installed versions of packages. To run all the migrations, invoke: + +```bash +nx migrate --run-migrations=migrations.json +``` + +For small projects, running all the migrations at once often succeeds without any issues. + +For large projects, more flexibility is often needed: + +- You may have to skip a migration. +- You may want to run one migration at a time to address minor issues. +- You may want to reorder migrations. +- You may want to run the same migration multiple time if the process takes a long time and you had to rebase. + +Since you can run `nx migrate --run-migrations=migrations.json` as many times as you want, you can achieve all of that by commenting out and reordering items in `migrations.json`. + +The migrate process can take a long time, sometimes day, so it can be useful to commit the migrations file. + +### Overriding versions + +Sometimes, you may want to use a different version of a package than what Nx recommends. You can do it as follows: + +```bash +nx migrate @nrwl/workspace --to="jest@22.0.0,cypress:3.4.0" +``` + +By default, Nx uses currently installed packages to calculate what migrations need to run. You can override them like this: + +```bash +nx migrate @nrwl/workspace --to="@nrwl/jest@8.0.0" +``` + +## Reverting a failed update + +Updates are best done on a clean git history so that it can be easily reversed if something fails. +We try our best to make sure migrations do not fail but if one does, **please report it** on [Github](https://www.github.com/nrwl/nx/issues/new/). +If an update fails for any reason, you can revert it as you do any other set of changes: + +```bash +git reset --hard # Reset any changes +git clean -fd # Delete newly added files and directories +``` + +## Updating Other Dependencies + +Nx does not handle updating the dependencies that Nx did not add. Please refer to those projects for the best updating strategy. + +## Using Angular CLI Update + +The `nx migrate` command uses the same migrations as `ng update`. You can use either command to update your workspace. + +The difference is that `nx migrate` gives you a lot more control over what gets installed, what migrations run, etc.. This is often needed for mid-size or large projects, where `ng-update` falls short. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angular.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angular.md new file mode 100644 index 0000000000..60bf3d20dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angular.md @@ -0,0 +1,380 @@ +# Transitioning to Nx + +Within an Nx workspace, you gain many capabilities that help you build applications and libraries +using a monorepo approach. If you are currently using an Angular CLI workspace, you can transform it into an Nx workspace. + +## Prerequisites + +- The major version of your `Angular CLI` must align with the version of `Nx` you are upgrading to. For example, if you're using Angular CLI version 7, you must transition using the latest version 7 release of Nx. +- Currently, transforming an Angular CLI workspace to an Nx workspace automatically only supports a single project. If you have more than one project in your Angular CLI workspace, you can still migrate manually. + +## Using ng add and preserving your existing structure + +To add Nx to an existing Angular CLI workspace to an Nx workspace, with keeping your existing file structure in place, use the `ng add` command with the `--preserveAngularCLILayout` option: + +``` +ng add @nrwl/workspace --preserveAngularCLILayout +``` + +This installs the `@nrwl/workspace` package into your workspace and applies the following changes to your workspace: + +- Adds and installs the `@nrwl/workspace` package in your development dependencies. +- Creates an nx.json file in the root of your workspace. +- Adds a `decorate-angular-cli.js` to the root of your workspace, and a `postinstall` script in your `package.json` to run the script when your dependencies are updated. The script forwards the `ng` commands to the Nx CLI(nx) to enable features such as Computation Caching. + +After the process completes, you continue using the same serve/build/lint/test commands. + +## Using ng add + +To transform a Angular CLI workspace to an Nx workspace, use the `ng add` command: + +``` +ng add @nrwl/workspace +``` + +This installs the `@nrwl/workspace` package into your workspace and runs a schematic to transform your workspace. The schematic applies the following changes to your workspace: + +- Installs the packages for the `Nx` plugin `@nrwl/angular` in your package.json. +- Creates an nx.json file in the root of your workspace. +- Creates configuration files for Prettier. +- Creates an `apps` folder for generating applications. +- Creates a `libs` folder for generating libraries. +- Creates a `tools` folder that includes files for custom workspace tooling, such as workspace-specific schematics and scripts. +- Moves your application into the `apps` folder, and updates the relevant file paths in your configuration files. +- Moves your e2e suite into the `apps/{{app name}}-e2e` folder, and updates the relevant file paths in your configuration files. +- Updates your `package.json` with scripts to run various `Nx` workspace commands. +- Updates your `angular.json` configuration to reflect the new paths. + +After the changes are applied, your workspace file structure should look similar to below: + +```treeview +/ +├── apps/ +│   ├── / +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.css +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── karma.conf.js +│   │   ├── tsconfig.app.json +│   │   └── tsconfig.spec.json +│   └── -e2e/ +│      ├── src/ +│      ├── protractor.conf.js +│      └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── angular.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Your workspace is now powered by Nx! You can verify out that your application still runs as intended: + +- To serve, run `ng serve`. +- To build, run `ng build`. +- To run unit tests, run `ng test`. +- To run e2e tests, run `ng e2e`. +- To see your dependency graph, run `nx dep-graph`. + +> Your dependency graph will grow as you add, and use more applications and libraries. + +Learn more about the advantages of Nx in the following guides: + +- [Using Cypress for e2e tests](/angular/plugins/cypress/overview) +- [Using Jest for unit tests](/angular/plugins/jest/overview) +- [Computation Caching](/angular/workspace/computation-caching) +- [Rebuilding and Retesting What is Affected](/angular/guides/ci/monorepo-affected) + +## Transitioning Manually + +If you are unable to automatically transform your Angular CLI workspace to an Nx workspace using the [ng add](/angular/guides/transition-to-nx#using-ng-add) method, there are some manual steps you can take to move your project(s) into an Nx workspace. + +### Generating a new workspace + +To start, run the command to generate an Nx workspace with an Angular application. + +**Using `npx`** + +```bash +npx create-nx-workspace myorg --preset=angular +``` + +**Using `npm init`** + +```bash +npm init nx-workspace myorg --preset=angular +``` + +**Using `yarn create`** + +```bash +yarn create nx-workspace myorg --preset=angular +``` + +When prompted for the `application name`, enter the _project name_ from your current `angular.json` file. + +A new Nx workspace with your `org name` as the folder name, and your `application name` as the first application is generated. + +```treeview +/ +├── apps/ +│   ├── / +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.css +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tslint.json +│   │   └── tsconfig.spec.json +│   └── -e2e/ +│      ├── src/ +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tslint.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── .prettierignore +├── .prettierrc +├── README.md +├── angular.json +├── jest.config.js +├── nx.json +├── package.json +├── tsconfig.json +└── tslint.json +``` + +### Copying over application files + +Your application code is self-contained within the `src` folder of your Angular CLI workspace. + +- Copy the `src` folder from your Angular CLI project to the `apps/` folder, overwriting the existing `src` folder. +- Copy any project-specific files, such as `browserslist`, or service worker configuration files into their relative path under the `apps/` folder. +- Transfer the `assets`, `scripts`, `styles`, and build-specific configuration, such as service worker configuration, from your Angular CLI `angular.json` to the Nx workspace `angular.json` file. + +Verify your app runs correctly by running: + +```sh +ng serve +``` + +### Updating your unit testing configuration + +Nx uses Jest by default. If you have any custom Jest configuration, you need to update the workspace Jest configuration also. + +Verify your tests run correctly by running: + +```sh +ng test +``` + +If you are using `Karma` for unit testing: + +- Copy the `karma.conf.js` file to your `apps/` folder. +- Copy the `test.ts` file to your `apps//src` folder. +- Copy the `test` target in your `architect` configuration from your Angular CLI `angular.json` file into your Nx workspace `angular.json` file. +- Update your `test` target to prepend `apps/` to each of the file paths. + +```json +{ + "version": 1, + "projects": { + "": { + "projectType": "application", + "schematics": {}, + "root": "apps/", + "sourceRoot": "apps//src", + "prefix": "myapp", + "architect": { + "test": { + "builder": "@angular-devkit/build-angular:karma", + "options": { + "main": "apps//src/test.ts", + "polyfills": "apps//src/polyfills.ts", + "tsConfig": "apps//tsconfig.spec.json", + "karmaConfig": "apps//karma.conf.js", + "assets": [ + "apps//src/favicon.ico", + "apps//src/assets" + ], + "styles": ["apps//src/styles.css"], + "scripts": [] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/angular" + }, + "schematics": { + "@nrwl/angular:application": { + "unitTestRunner": "jest", + "e2eTestRunner": "cypress" + }, + "@nrwl/angular:library": { + "unitTestRunner": "jest" + } + }, + "defaultProject": "" +} +``` + +> Jest will be used by default when generating new applications. If you want to continue using `Karma`, set the `unitTestRunner` to `karma` in the `schematics` section of the `angular.json` file. + +- Update `test-setup.ts` to `test.ts` in the `files` array of the `apps//tsconfig.spec.json` file. + +```json +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../dist/out-tsc", + "module": "commonjs", + "types": ["node"] + }, + "files": ["src/test.ts", "src/polyfills.ts"], + "include": ["**/*.spec.ts", "**/*.d.ts"] +} +``` + +Verify your tests run correctly by running: + +```sh +ng test +``` + +### Updating your E2E testing configuration + +Nx uses Cypress by default. If you are already using Cypress, copy your E2E setup files into the `apps/-e2e` folder and verify your tests still run correctly by running: + +```sh +ng e2e -e2e +``` + +If you are using `Protractor` for E2E testing: + +- Delete the `apps/-e2e` folder that was generated to use Cypress. +- Copy the `e2e` folder from your Angular CLI workspace into the `apps` file to your `apps/` folder. +- Rename the `e2e` folder to `-e2e`. +- In the Nx workspace `angular.json`, update your `-e2e` project with the `Protractor` configuration. + +```json +{ + "version": 1, + "projects": { + "-e2e": { + "root": "apps/-e2e", + "projectType": "application", + "architect": { + "e2e": { + "builder": "@angular-devkit/build-angular:protractor", + "options": { + "protractorConfig": "apps/-e2e/protractor.conf.js", + "devServerTarget": ":serve" + }, + "configurations": { + "production": { + "devServerTarget": ":serve:production" + } + } + }, + "lint": { + "builder": "@angular-devkit/build-angular:tslint", + "options": { + "tsConfig": "apps/-e2e/tsconfig.e2e.json", + "exclude": ["**/node_modules/**", "!apps/-e2e/**/*"] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/angular" + }, + "schematics": { + "@nrwl/angular:application": { + "unitTestRunner": "jest", + "e2eTestRunner": "cypress" + }, + "@nrwl/angular:library": { + "unitTestRunner": "jest" + } + }, + "defaultProject": "" +} +``` + +Create a `tsconfig.e2e.json` file under `apps/-e2e` folder: + +```json +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../dist/out-tsc" + } +} +``` + +Update the `apps//tsconfig.json` to extend the root `tsconfig.json`: + +```json +{ + "extends": "../../tsconfig.json", + "compilerOptions": { + "outDir": "../../out-tsc/-e2e", + "module": "commonjs", + "target": "es5", + "types": ["jasmine", "jasminewd2", "node"] + } +} +``` + +Verify your E2E tests run correctly by running: + +```sh +ng e2e -e2e +``` + +> Cypress will be used by default when generating new applications. If you want to continue using `Protractor`, set the `e2eTestRunner` to `protractor` in the `schematics` section of the `angular.json` file. + +### Updating your linting configuration + +For lint rules, migrate your existing rules into the root `tslint.json` file. + +Verify your lint checks run correctly by running: + +```sh +npm run lint +``` + +OR + +```sh +yarn lint +``` + +Learn more about the advantages of Nx in the following guides: + +[Using Cypress for e2e tests](/angular/plugins/cypress/overview) \ +[Using Jest for unit tests](/angular/plugins/jest/overview) \ +[Rebuilding and Retesting What is Affected](/angular/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs-unit-tests-passing.png b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs-unit-tests-passing.png new file mode 100644 index 0000000000..53414ab08c Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs-unit-tests-passing.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs.md new file mode 100644 index 0000000000..4938946027 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/migration/migration-angularjs.md @@ -0,0 +1,684 @@ +# Migrating an AngularJS Project into an Nx Workspace + +Nx offers first-class support for Angular and React out-of-the-box. But one of the questions the Nrwl team often hears from our community is how to use AngularJS (Angular 1.x) in Nx. Nx is a great choice for managing an AngularJS to Angular upgrade, or just for consolidating your existing polyrepo approach to AngularJS into a monorepo to make maintenance a little easier. + +In this article, you’ll learn how to: + +- Create an Nx workspace for an AngularJS application +- Migrate an AngularJS application into your Nx workspace +- Convert an existing build process for use in Nx +- Use Webpack to build an AngularJS application +- Run unit and end-to-end tests + +For this example, you’ll be migrating the [Real World AngularJS](https://github.com/gothinkster/angularjs-realworld-example-app) application from [Thinkster.io](https://thinkster.io/). You should clone this repo so you have access to the code before beginning. + +There is also a [repo](https://github.com/nrwl/nx-migrate-angularjs-example) that shows a completed example of this guide. + +> The RealWorld app is a great example of an AngularJS app, but it probably doesn’t have the complexity of your own codebase. As you go along, I’ll include some recommendations on how you might apply this example to your larger, more complex application. + +## Creating your workspace + +To start migrating the Real World app, create an Nx workspace: + +```bash +npx create-nx-workspace@latest nx-migrate-angularjs +``` + +When prompted choose the `empty` preset. The other presets use certain recommended defaults for the workspace configuration. Because you have existing code with specific requirements for configuration, starting with a blank workspace avoids resetting these defaults. This will give you the ability to customize the workspace for the incoming code. + +At the next prompt, choose `Angular CLI` for your workspace CLI. While you may not be using Angular now, this gives you the best option to upgrade to Angular later. The Angular CLI is also the best CLI option for using Karma and Protractor, the two testing suites most commonly used for AngularJS. + +```bash +? What to create in the new workspace empty [an empty workspace] +? CLI to power the Nx workspace Angular CLI [Extensible CLI for Angular applications. Recommended for Angular projects.] +``` + +## Creating your app + +Your new workspace won’t have much in it because of the `empty` preset. You’ll need to generate an application to have some structure created. Add the Angular capability to your workspace: + +```bash +ng add @nrwl/angular +``` + +When prompted, make a choice of unit test runner and e2e test runner: + +```bash +? Which Unit Test Runner would you like to use for the application? Karma [ https://karma-runner.github.io ] +? Which E2E Test Runner would you like to use? Protractor [ https://www.protractortest.org ] +``` + +For this example, we will use Karma and Protractor, the most common unit test runner and e2e test runner for AngularJS. + +> Codebases with existing unit and e2e tests should continue to use whatever runner they need. We’ve chosen Karma and Protractor here because it’s the most common. If you’re going to be adding unit testing or e2e as part of this transition and are starting fresh, we recommend starting with Jest and Cypress. + +With the Angular capability added, generate your application: + +```bash +ng generate @nrwl/angular:application --name=realworld +``` + +Accept the default options for each prompt: + +```bash +? Which stylesheet format would you like to use? CSS +? Would you like to configure routing for this application? No +``` + +> The RealWorld app doesn’t have any styles to actually bundle here. They’re all downloaded from a CDN that all of the RealWorld apps use. If your codebase uses something other than CSS, like Sass or PostCSS, you can choose that here. + +## Migrating dependencies + +Copy the dependencies from the RealWorld app’s `package.json` to the `package.json` in your workspace. Split the existing dependencies into `dependencies` (application libraries) and `devDependencies` (build and test libraries). Everything related to gulp can go into `devDependencies`. + +Your `package.json` should now look like this: + +```json +{ + "name": "nx-migrate-angularjs", + "version": "0.0.0", + "license": "MIT", + "scripts": { + "ng": "ng", + "nx": "nx", + "start": "ng serve", + "build": "ng build", + "test": "ng test", + "lint": "nx workspace-lint && ng lint", + "e2e": "ng e2e", + "affected:apps": "nx affected:apps", + "affected:libs": "nx affected:libs", + "affected:build": "nx affected:build", + "affected:e2e": "nx affected:e2e", + "affected:test": "nx affected:test", + "affected:lint": "nx affected:lint", + "affected:dep-graph": "nx affected:dep-graph", + "affected": "nx affected", + "format": "nx format:write", + "format:write": "nx format:write", + "format:check": "nx format:check", + "update": "ng update @nrwl/workspace", + "workspace-schematic": "nx workspace-schematic", + "dep-graph": "nx dep-graph", + "help": "nx help", + "postinstall": "ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points" + }, + "private": true, + "dependencies": { + "@nrwl/angular": "^9.0.4", + "@angular/animations": "9.0.0", + "@angular/common": "9.0.0", + "@angular/compiler": "9.0.0", + "@angular/core": "9.0.0", + "@angular/forms": "9.0.0", + "@angular/platform-browser": "9.0.0", + "@angular/platform-browser-dynamic": "9.0.0", + "@angular/router": "9.0.0", + "angular": "^1.5.0-rc.2", + "angular-ui-router": "^0.4.2", + "core-js": "^2.5.4", + "rxjs": "~6.5.0", + "zone.js": "^0.10.2" + }, + "devDependencies": { + "@angular/cli": "9.0.1", + "@nrwl/workspace": "9.0.4", + "@types/node": "~8.9.4", + "dotenv": "6.2.0", + "ts-node": "~7.0.0", + "tslint": "~5.11.0", + "eslint": "6.1.0", + "typescript": "~3.7.4", + "prettier": "1.18.2", + "@angular/compiler-cli": "9.0.0", + "@angular/language-service": "9.0.0", + "@angular-devkit/build-angular": "0.900.1", + "codelyzer": "~5.0.1", + "karma": "~4.0.0", + "karma-chrome-launcher": "~2.2.0", + "karma-coverage-istanbul-reporter": "~2.0.1", + "karma-jasmine": "~1.1.2", + "karma-jasmine-html-reporter": "^0.2.2", + "jasmine-core": "~2.99.1", + "jasmine-spec-reporter": "~4.2.1", + "@types/jasmine": "~2.8.8", + "protractor": "~5.4.0", + "@types/jasminewd2": "~2.0.3", + "babel-preset-es2015": "^6.3.13", + "babelify": "^7.2.0", + "browser-sync": "^2.11.1", + "browserify": "^13.0.0", + "browserify-ngannotate": "^2.0.0", + "gulp": "^3.9.1", + "gulp-angular-templatecache": "^1.8.0", + "gulp-notify": "^2.2.0", + "gulp-rename": "^1.2.2", + "gulp-uglify": "^1.5.3", + "gulp-util": "^3.0.7", + "marked": "^0.3.5", + "merge-stream": "^1.0.0", + "vinyl-source-stream": "^1.1.0" + } +} +``` + +Run `npm install` to install all of your new dependencies. + +> For your own project, you’ll need to switch to NPM if you’re using another package manager like bower. [Learn more about switching away from bower](https://bower.io/blog/2017/how-to-migrate-away-from-bower/) + +## Migrating application code + +This Angular application that you generated has the configuration that you need, but you don’t need any of its application code. You’ll replace that with the RealWorld app code. Delete the contents of `apps/realworld/src/app`. + +Starting in the `js` folder of the realworld app, copy all of the application code into `apps/realworld/src/app`. The resulting file tree should look like this: + +```text +apps +|____realworld-e2e +|____realworld +| |____src +| | |____index.html +| | |____app +| | | |____settings +| | | |____home +| | | |____config +| | | |____auth +| | | |____layout +| | | |____components +| | | |____profile +| | | |____article +| | | |____services +| | | |____editor +| | | |____app.js\ +| | |____styles.css +| | |____environments +| | |____main.ts +| | |____test.ts +| | |____assets +``` + +> You most likely have your own AngularJS project written in JavaScript as well. While you’ll continue to use JavaScript through the rest of this example, we strongly recommend switching AngularJS projects to TypeScript, especially if you’re planning an upgrade to Angular. + +## Modifying index.html and main.ts + +Your generated application will also have an `index.html` provided. However, it’s set up for an Angular application, not an AngularJS application. Replace the contents of `apps/realworld/src/index.html` with the `index.html` from the RealWorld app. + +Your application also has a `main.ts` file which is responsible for bootstrapping your app. Again, you don’t need much from this file any more. Replace its contents with: + +```typescript +import ‘./app/app.js’; +``` + +And re-name it to `main.js`. This will import the existing app.js file from the RealWorld app which will bootstrap the app. + +## Adding existing build and serve processes + +If you’re looking at the example repo, the code for this section is available on branch `initial-migration`. This section is an interim step that continues to use gulp to build and serve the app locally. You’ll replace gulp in the next section. The RealWorld app uses gulp 3.9.1 to build. This version is not supported anymore and doesn’t run on any version of Node greater than 10.\*. To build this using gulp, you need to install an appropriate version of Node and make sure you re-install your dependencies. If this isn’t possible (or you just don’t want to), feel free to skip to the next section. The webpack build process should run in any modern Node version. + +The RealWorld app uses gulp to build the application, as well as provide a development server. To verify that the migration has worked, stay with that build process for now. + +> During migration, you should take a small step and confirm that things work before moving ahead. Stopping and checking to see that your app still builds and functions is essential to a successful migration. + +Copy the `gulpfile.js` over from the RealWorld app and put it in `apps/realworld`. This is where all configuration files reside for the application. Make some adjustments to this file so that your build artifacts land in a different place. In an Nx workspace, all build artifacts should be sent to an app-specific folder in the `dist` folder at the root of your workspace. Your `gulpfile.js` should look like this: + +```javascript +var gulp = require('gulp'); +var notify = require('gulp-notify'); +var source = require('vinyl-source-stream'); +var browserify = require('browserify'); +var babelify = require('babelify'); +var ngAnnotate = require('browserify-ngannotate'); +var browserSync = require('browser-sync').create(); +var rename = require('gulp-rename'); +var templateCache = require('gulp-angular-templatecache'); +var uglify = require('gulp-uglify'); +var merge = require('merge-stream'); + +// Where our files are located +var jsFiles = 'src/app/**/*.js'; +var viewFiles = 'src/app/**/*.html'; + +var interceptErrors = function (error) { + var args = Array.prototype.slice.call(arguments); + + // Send error to notification center with gulp-notify + notify + .onError({ + title: 'Compile Error', + message: '<%= error.message %>', + }) + .apply(this, args); + + // Keep gulp from hanging on this task + this.emit('end'); +}; + +gulp.task('browserify', ['views'], function () { + return ( + browserify('./src/main.js') + .transform(babelify, { presets: ['es2015'] }) + .transform(ngAnnotate) + .bundle() + .on('error', interceptErrors) + //Pass desired output filename to vinyl-source-stream + .pipe(source('main.js')) + // Start piping stream to tasks! + .pipe(gulp.dest('../../dist/apps/realworld/')) + ); +}); + +gulp.task('html', function () { + return gulp + .src('src/index.html') + .on('error', interceptErrors) + .pipe(gulp.dest('../../dist/apps/realworld/')); +}); + +gulp.task('views', function () { + return gulp + .src(viewFiles) + .pipe( + templateCache({ + standalone: true, + }) + ) + .on('error', interceptErrors) + .pipe(rename('app.templates.js')) + .pipe(gulp.dest('src/app/config')); +}); + +// This task is used for building production ready +// minified JS/CSS files into the dist/ folder +gulp.task('build', ['html', 'browserify'], function () { + var html = gulp + .src('../../dist/apps/realworld/index.html') + .pipe(gulp.dest('../../dist/apps/realworld/')); + + var js = gulp + .src('../../dist/apps/realworld/main.js') + .pipe(uglify()) + .pipe(gulp.dest('../../dist/apps/realworld/')); + + return merge(html, js); +}); + +gulp.task('default', ['html', 'browserify'], function () { + browserSync.init(['../../dist/apps/realworld/**/**.**'], { + server: '../../dist/apps/realworld', + port: 4000, + notify: false, + ui: { + port: 4001, + }, + }); + + gulp.watch('src/index.html', ['html']); + gulp.watch(viewFiles, ['views']); + gulp.watch(jsFiles, ['browserify']); +}); +``` + +You need to point your `build` and `serve` tasks at this gulp build process. Typically, an Angular app is built using the Angular CLI, but the Angular CLI doesn’t know how to build AngularJS projects. All of your tasks are configured in the `angular.json` file. Find the `build` and `serve` tasks and replace them with this code block: + +```json +... + "build": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx gulp --gulpfile apps/realworld/gulpfile.js build" + } + ] + } + }, + "serve": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx gulp --gulpfile apps/realworld/gulpfile.js" + } + ] + } + }, +... +``` + +This sets up the `build` and `serve` commands to use the locally installed version of gulp to run `build` and `serve`. To see the RealWorld app working, run + +```bash +ng serve realworld +``` + +Navigate around the application and see that things work. + +> Your own project might not be using gulp. If you’re using webpack, you can follow the next section and substitute your own webpack configuration. If you’re using something else like grunt or a home-grown solution, you can follow the same steps here to use it. You’ll use the `run-commands` builder and substitute in the commands for your project. + +## Switching to webpack + +So far, you’ve mostly gotten already existing code and processes to work. This is the best way to get started with any migration: get existing code to work before you start making changes. This gives you a good, stable base to build on. It also means you having working code now rather than hoping you’ll have working code in the future! + +But migrating AngularJS code means we need to switch some of our tools to a more modern tool stack. Specifically, using webpack and babel is going to allow us to take advantage of Nx more easily. Becoming an expert in these build tools is outside the scope of this article, but I’ll address some AngularJS specific concerns. To get started, install a new dependency: + +```bash +npm install babel-plugin-angularjs-annotate +``` + +Nx already has most of what you need for webpack added as a dependency. `babel-plugin-angularjs-annotate` is going to accomplish the same thing that `browserify-ngannotate` previously did in gulp: add dependency injection annotations. + +Start with a `webpack.config.js` file in your application’s root directory: + +```javascript +const path = require('path'); + +module.exports = (config, context) => { + return { + ...config, + module: { + strictExportPresence: true, + rules: [ + { + test: /\.html$/, + use: [{ loader: 'raw-loader' }], + }, + // Load js files through Babel + { + test: /\.(js|jsx)$/, + loader: 'babel-loader', + options: { + presets: ['@babel/preset-env'], + plugins: ['angularjs-annotate'], + }, + }, + ], + }, + }; +}; +``` + +> This webpack configuration is deliberately simplified for this tutorial. A real production-ready webpack config for your project will be much more involved. See [this project](https://github.com/preboot/angularjs-webpack) for an example. + +To use webpack instead of gulp, go back to your `angular.json` file and modify the `build` and `serve` commands again: + +```json +... +"build": { + "builder": "@nrwl/web:build", + "options": { + "outputPath": "dist/apps/realworld", + "index": "apps/realworld/src/index.html", + "main": "apps/realworld/src/main.ts", + "polyfills": "apps/realworld/src/polyfills.ts", + "tsConfig": "apps/realworld/tsconfig.app.json", + "assets": [ + "apps/realworld/src/favicon.ico", + "apps/realworld/src/assets" + ], + "styles": ["apps/realworld/src/styles.css"], + "scripts": [], + "webpackConfig": "apps/realworld/webpack.config", + "buildLibsFromSource": true + }, + "configurations": { + "production": { + "fileReplacements": [ + { + "replace": "apps/realworld/src/environments/environment.ts", + "with": "apps/realworld/src/environments/environment.prod.ts" + } + ], + "optimization": true, + "outputHashing": "all", + "sourceMap": false, + "extractCss": true, + "namedChunks": false, + "extractLicenses": true, + "vendorChunk": false, + "budgets": [ + { + "type": "initial", + "maximumWarning": "2mb", + "maximumError": "5mb" + } + ] + } + } +}, +"serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "realworld:build" + } +}, +... +``` + +You may have noticed a rule for loading HTML in `webpack.config.js`. You need to modify some of your AngularJS code to load HTML differently. The application previously used the template cache to store all of the component templates in code, rather than download them at run time. This works, but you can do things a little better with webpack. + +Rather than assigning `templateUrl` for your components, you can instead import the HTML and assign it to the `template` attribute. This is effectively the same as writing your templates in-line, but you still have the benefit of having a separate HTML file. The advantage is that the template is tied to its component, not a global module like the template cache. Loading all templates into the template cache is more performant than individually downloading templates, but it also means your user is downloading every single component’s template as part of start-up. This was fine in AngularJS when you didn’t easily have access to lazy-loading, so you always had a large up-front download cost. As you begin to upgrade to Angular or other modern frontend frameworks, you will gain access to lazy-loading: only loading code when it’s necessary. By making this change now, you set yourself up for success later. + +To accomplish this, open `config/app.config.js` which is the main app component. Modify it like this: + +```javascript +import authInterceptor from './auth.interceptor'; +import template from '../layout/app-view.html'; + +function AppConfig( + $httpProvider, + $stateProvider, + $locationProvider, + $urlRouterProvider +) { + 'ngInject'; + + $httpProvider.interceptors.push(authInterceptor); + + /* + If you don't want hashbang routing, uncomment this line. + Our tutorial will be using hashbang routing though :) + */ + // $locationProvider.html5Mode(true); + + $stateProvider.state('app', { + abstract: true, + template, + resolve: { + auth: function (User) { + return User.verifyAuth(); + }, + }, + }); + + $urlRouterProvider.otherwise('/'); +} + +export default AppConfig; +``` + +This change loads the HTML code directly and sets it to the template attribute of the component. The HTML rule that you specified in the webpack config will take care of loading the HTML correctly and adding it to the template like this. + +Now, go through each component of the application and make this change. To make sure that you’ve really modified every component correctly, delete the template cache file (`config/app.templates.js`) that gulp generated earlier. + +> In an example like this, it’s easy enough to make this kind of change by hand. In a larger codebase, doing this manually could be very time-intensive. You’ll want to look into an automated tool to do this for you, such as js-codemod or schematics. + +Run the application the same way as before: + +```bash +ng serve realworld +``` + +## Unit testing + +Unit testing can be an important part of any code migration. If you migrate your code into a new system, and all of your unit tests pass, you have a higher degree of confidence that your application actually works without manually testing. Unfortunately, the RealWorld application doesn’t have any unit tests, but you can add your own. + +You need a few dependencies for AngularJS unit testing that Nx doesn’t provide by default: + +```bash +npm install angular-mocks@1.5.11 karma-webpack +``` + +Earlier, you configured this app to use Karma as its unit test runner. Nx has provided a Karma config file for you, but you’ll need to modify it to work with AngularJS: + +```javascript +const webpack = require('./webpack.config'); +const getBaseKarmaConfig = require('../../karma.conf'); + +module.exports = function (config) { + const baseConfig = getBaseKarmaConfig(); + config.set({ + ...baseConfig, + frameworks: ['jasmine'], + plugins: [ + require('karma-jasmine'), + require('karma-chrome-launcher'), + require('karma-jasmine-html-reporter'), + require('karma-coverage-istanbul-reporter'), + require('karma-webpack'), + ], + // This will be the new entry to webpack + // so it should just be a single file + files: ['src/test.js'], + + // Preprocess test index and test files using + // webpack (will run babel) + preprocessors: { + 'src/test.js': ['webpack'], + 'src/**/*.spec.js': ['webpack'], + }, + + // Reference webpack config (single object) + // and configure some middleware settings + webpack: { + ...webpack({}), + mode: 'development', + }, + webpackMiddleware: { + noInfo: true, + stats: 'errors-only', + }, + + // Typical Karma settings, see docs + reporters: ['progress'], + port: 9876, + colors: true, + logLevel: config.LOG_INFO, + autoWatch: true, + browsers: ['ChromeHeadless'], + singleRun: true, + concurrency: Infinity, + }); +}; +``` + +Now add a unit test for the comment component: + +```javascript +import articleModule from './index'; + +beforeEach(() => { + // Create the module where our functionality can attach to + angular.mock.module('ui.router'); + angular.mock.module(articleModule.name); +}); + +let component; + +beforeEach( + angular.mock.inject(($rootScope, $componentController) => { + let User = { + current: false, + }; + component = $componentController('comment', { User }); + }) +); + +describe('comment component', () => { + it('should be defined', () => { + expect(component).toBeDefined(); + }); + + it('should default canModify to false', () => { + expect(component.canModify).toEqual(false); + }); +}); +``` + +This unit test does a check to make sure the component compiles and that it sets default permissions correctly. + +To run the unit tests: + +```bash +ng test +``` + +You should see green text as your test passes. + +![Unit tests passing](./migration-angularjs-unit-tests-passing.png) + +## End to End testing + +End to End (or E2E) testing is another important part of migration. The more tests you have to verify your code, the easier it is to confirm that your code works the same way it did before. Again, the realworld application doesn’t have any e2e tests, so you need to add your own. + +Nx created `realworld-e2e` for you when you generated your app. There is an example test already generated in `apps/realworld-e2e/src/app.e2e-spec.ts`. It has a helper file named `app.po.ts`. The `spec` file contains the actual tests, while the `po` file contains helper functions to retrieve information about the page. The generated test checks to make sure the title of the app is displayed properly, an indication that the app bootstrapped properly in the browser. + +You need to modify these files to account for the RealWorld app layout. Make the following modifications: + +```typescript +//app.e2e-spec.ts +import { AppPage } from './app.po'; +import { browser, logging } from 'protractor'; + +describe('workspace-project App', () => { + let page: AppPage; + + beforeEach(() => { + page = new AppPage(); + }); + + it('should display app title', () => { + page.navigateTo(); + expect(page.getTitleText()).toEqual('conduit'); + }); + + afterEach(async () => { + // Assert that there are no errors emitted from the browser + const logs = await browser.manage().logs().get(logging.Type.BROWSER); + expect(logs).not.toContain( + jasmine.objectContaining({ + level: logging.Level.SEVERE, + } as logging.Entry) + ); + }); +}); +``` + +```typescript +// app.po.ts +import { browser, by, element } from 'protractor'; + +export class AppPage { + navigateTo(): Promise { + return browser.get(browser.baseUrl) as Promise; + } + + getTitleText(): Promise { + return element(by.css('h1.logo-font')).getText() as Promise; + } +} +``` + +To run e2e tests, use the `e2e` command: + +```bash +ng e2e +``` + +You should see a browser pop up to run the Protractor tests and then green success text in your console. + +## Summary + +- Nx workspaces can be customized to support AngularJS projects +- AngularJS projects can be migrated into an Nx workspace using existing build and serve processes +- Switching to Webpack can enable your Angular upgrade success later +- Unit testing and e2e testing can be used on AngularJS projects and can help ensure a successful migration diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/schematics.json b/nx-dev/data-access-documents/src/data/10.4.13/angular/schematics.json new file mode 100644 index 0000000000..ae621ac6e8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/schematics.json @@ -0,0 +1,14 @@ +[ + "angular", + "cypress", + "express", + "jest", + "nest", + "next", + "node", + "nx-plugin", + "react", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/01-create-application.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/01-create-application.md new file mode 100644 index 0000000000..d28468eb0e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/01-create-application.md @@ -0,0 +1,126 @@ +# Step 1: Create Application + +## Video of this Lesson + + + +In this tutorial you will use Nx to build a full-stack application out of common libraries using modern technologies like Cypress and Nest. + +## Create a New Workspace + +**Start by creating a new workspace.** + +```bash +npx create-nx-workspace@latest + +? Workspace name (e.g., org name) myorg +? What to create in the new workspace angular +? Application name todos +? Default stylesheet format CSS +``` + +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.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── tslint.json +│   └── todos-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tsconfig.json +│      └── tslint.json +├── libs/ +├── tools/ +├── angular.json +├── nx.json +├── package.json +├── tsconfig.json +├── tslint.json +└── README.md +``` + +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 `npm run`: + +```bash +npm run nx -- serve todos +``` + +or + +```bash +yarn nx serve todos +``` + +## Note on `nx serve` and `ng serve` + +Internally, the Nx CLI delegates to the Angular CLI when running commands or generating code. 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 `ng` will result in the same output, but often will perform a lot better. [Read more about Nx CLI and Angular CLI.](/angular/cli/nx-and-cli) + +!!!!! +Open http://localhost:4200 in the browser. What do you see? +!!!!! +Page saying "Welcome to Todos!" +Page saying "This is an Angular app built with the Angular CLI" +404 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/02-add-e2e-test.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/02-add-e2e-test.md new file mode 100644 index 0000000000..34e3541ab5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/02-add-e2e-test.md @@ -0,0 +1,48 @@ +# Step 2: Add E2E Tests + +## Video of this Lesson + + + +By default, Nx uses [Cypress](/{{framework}}/plugins/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 not a great example of an E2E test, but it will suffice 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 will open. Click the button in the top right corner that says "Run all specs". Keep the E2E tests running. + +As you progress through the tutorial, you will work on making these E2E tests pass. + +!!!!! +What assertion fails? +!!!!! +Expect 0 to equal 2 +Nothing fails. Everything works. +Cannot find any elements matching 'li.todo' +Cannot find any elements matching 'button#add-todo' diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/03-display-todos.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/03-display-todos.md new file mode 100644 index 0000000000..6eb024640f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/03-display-todos.md @@ -0,0 +1,89 @@ +# Step 3: Display Todos + +## Video of this Lesson + + + +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 test will 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 will you see if you run: `npx nx e2e todos-e2e --headless` +!!!!! +Cypress will run in the headless mode, and the test will pass. +Cypress will run in the headless mode, and the test will fail. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/04-connect-to-api.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/04-connect-to-api.md new file mode 100644 index 0000000000..0f23ed8b79 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/04-connect-to-api.md @@ -0,0 +1,66 @@ +# Step 4: Connect to an API + +## Video of this Lesson + + + +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(); + }); + } +} +``` + +!!!!! +Run `npx nx serve todos` and open http://localhost:4200. What do you see? +!!!!! +"the server responded with a status of 404 (Not Found)" in Console. +Blank screen. +Exception rendered on the screen. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/05-add-node-app.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/05-add-node-app.md new file mode 100644 index 0000000000..1f09cba585 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/05-add-node-app.md @@ -0,0 +1,190 @@ +# Step 5: Add Node Application Implementing API + +## Video of this Lesson + + + +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 open platform with plugins for many modern tools and frameworks. **To see some plugins, run `nx list`:** + +```bash +> NX Installed plugins: + + @nrwl/angular (builders,schematics) + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/workspace (builders,schematics) + + +> NX Also available: + + @nrwl/express (builders,schematics) + @nrwl/linter (builders) + @nrwl/nest (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-plugin (builders,schematics) + @nrwl/react (builders,schematics) + @nrwl/storybook (builders,schematics) + @nrwl/web (builders,schematics) + + +> NX Community plugins: + + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + @offeringsolutions/nx-karma-to-jest - Nx plugin for replacing karma with jest in an Nx workspace + @dev-thought/nx-deploy-it - Nx plugin to deploy applications on your favorite cloud provider +``` + +**Now run `npx nx list @nrwl/nest`, and you will see:** + +```bash +> NX NOTE @nrwl/nest is not currently installed + + Use "yarn add --dev @nrwl/nest" to add new capabilities +``` + +**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 will ask you a few questions, and, as with the Angular application, the defaults will 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 +│      └── tslint.json +├── libs/ +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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](/{{framework}}/plugins/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(); + } +} +``` + +!!!!! +Run "npx nx serve api" and open http://localhost:3333/api/todos. What do you see? +!!!!! +`[{"title":"Todo 1"},{"title":"Todo 2"}]` +Blank screen +404 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/06-proxy.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/06-proxy.md new file mode 100644 index 0000000000..4dc74e5fb2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/06-proxy.md @@ -0,0 +1,50 @@ +# Step 6: Proxy + +## Video of this Lesson + + + +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 `angular.json` and find the `serve` target of the todos app.** + +```json +{ + "serve": { + "builder": "@angular-devkit/build-angular:dev-server", + "options": { + "browserTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "browserTarget": "todos:build:production" + } + } + } +} +``` + +**Note the `proxyConfig` property.** + +**Now open `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. + +!!!!! +Now run both "npx nx serve todos" and "npx nx serve api" in separate terminals, open http://localhost:4200. What do you see +!!!!! +Todos application is working! +404 in the console +Todos are displayed but the Add Todo button doesn't work diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/07-share-code.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/07-share-code.md new file mode 100644 index 0000000000..86ae8e3be1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/07-share-code.md @@ -0,0 +1,118 @@ +# Step 7: Share Code + +## Video of this Lesson + + + +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 generator 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.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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 recognised. This may need to be done **every time a new workspace library is added**. + +## 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`. **So restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between frontend and backend apps +Between different frontend apps +Between different node apps diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/08-create-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/08-create-libs.md new file mode 100644 index 0000000000..3b81fc4295 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/08-create-libs.md @@ -0,0 +1,163 @@ +# Step 8: Create Libs + +## Video of this Lesson + + + +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. + +**Run `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.spec.ts +│      │   │ └── ui.module.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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.spec.ts +│      │   │ └── ui.module.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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 both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +angular.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/09-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/09-dep-graph.md new file mode 100644 index 0000000000..483db717f2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/09-dep-graph.md @@ -0,0 +1,18 @@ +# Step 9: Dep Graph + +## Video of this Lesson + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "npm run dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/10-computation-caching.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/10-computation-caching.md new file mode 100644 index 0000000000..370220478c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/10-computation-caching.md @@ -0,0 +1,108 @@ +# Step 10: Computation Caching + +## Video of this Lesson + + + +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 +> npx nx run todos:build +Generating ES5 bundles for differential loading... +ES5 bundle generation complete. + +chunk {runtime} runtime-es2015.js, runtime-es2015.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {runtime} runtime-es5.js, runtime-es5.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {polyfills} polyfills-es2015.js, polyfills-es2015.js.map (polyfills) 141 kB [initial] [rendered] +chunk {main} main-es2015.js, main-es2015.js.map (main) 22.7 kB [initial] [rendered] +chunk {main} main-es5.js, main-es5.js.map (main) 24.1 kB [initial] [rendered] +chunk {styles} styles-es2015.js, styles-es2015.js.map (styles) 9.88 kB [initial] [rendered] +chunk {styles} styles-es5.js, styles-es5.js.map (styles) 11.1 kB [initial] [rendered] +chunk {polyfills-es5} polyfills-es5.js, polyfills-es5.js.map (polyfills-es5) 759 kB [initial] [rendered] +chunk {vendor} vendor-es2015.js, vendor-es2015.js.map (vendor) 2.35 MB [initial] [rendered] +chunk {vendor} vendor-es5.js, vendor-es5.js.map (vendor) 2.75 MB [initial] [rendered] +``` + +**Now, run `npx nx build todos` again, and you will see the results appearing instantly:** + +```bash +> npx nx run todos:build + +> NX NOTE Cached Output: + +Generating ES5 bundles for differential loading... +ES5 bundle generation complete. + +chunk {polyfills-es5} polyfills-es5.js, polyfills-es5.js.map (polyfills-es5) 759 kB [initial] [rendered] +chunk {polyfills} polyfills-es2015.js, polyfills-es2015.js.map (polyfills) 141 kB [initial] [rendered] +chunk {main} main-es2015.js, main-es2015.js.map (main) 22.5 kB [initial] [rendered] +chunk {main} main-es5.js, main-es5.js.map (main) 23.9 kB [initial] [rendered] +chunk {vendor} vendor-es2015.js, vendor-es2015.js.map (vendor) 2.35 MB [initial] [rendered] +chunk {vendor} vendor-es5.js, vendor-es5.js.map (vendor) 2.75 MB [initial] [rendered] +chunk {styles} styles-es2015.js, styles-es2015.js.map (styles) 9.88 kB [initial] [rendered] +chunk {styles} styles-es5.js, styles-es5.js.map (styles) 11.1 kB [initial] [rendered] +chunk {runtime} runtime-es2015.js, runtime-es2015.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {runtime} runtime-es5.js, runtime-es5.js.map (runtime) 6.16 kB [entry] [rendered] +``` + +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` will run the command every single time. + +## Building Multiple Projects + +**Now, run `npx nx run-many --target=build --projects=todos,api` to rebuild the two applications:** + +```bash +Nx read the output from cache instead of running the command for 1 out of 2 projects. +``` + +Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache here [here](/{{framework}}/workspace/computation-caching). + +## --with-deps + +As we saw already, Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `npx nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> npx nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +> npx nx run ui:lint + +Linting "ui"... + +All files pass linting. + + +> npx nx run data:lint + +Linting "data"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `npx nx lint api --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 2 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/11-test-affected-projects.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/11-test-affected-projects.md new file mode 100644 index 0000000000..c0d2c34ed4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/11-test-affected-projects.md @@ -0,0 +1,70 @@ +# Step 11: Test Affected Projects + +## Video of this Lesson + + + +Because Nx understands the dependency graph of your workspace, Nx can be 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 `npm run affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps can be affected by this change. + +**Run `npm run affected:libs`**, and 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 `npx nx affected:test` to retest only the projects affected by the change.** + +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 `npm run affected:test -- --only-failed` to retest the failed projects.** + +## 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 +``` + +!!!!! +Run "npx nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects to run test +The `todos` project failed as before +`Cannot run tests against master` error diff --git a/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/12-summary.md b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/12-summary.md new file mode 100644 index 0000000000..c16ce711ac --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/angular/tutorial/12-summary.md @@ -0,0 +1,18 @@ +# 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 dep graph capabilities 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](/{{framework}}/cli/overview) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/builders.json b/nx-dev/data-access-documents/src/data/10.4.13/builders.json new file mode 100644 index 0000000000..d147d35dea --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/builders.json @@ -0,0 +1,11 @@ +[ + "cypress", + "express", + "jest", + "linter", + "nest", + "node", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/map.json b/nx-dev/data-access-documents/src/data/10.4.13/map.json new file mode 100644 index 0000000000..1cba380bf4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/map.json @@ -0,0 +1,3154 @@ +[ + { + "id": "angular", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Why Nx?", + "id": "why-nx", + "file": "angular/getting-started/why-nx" + }, + { + "name": "Resources", + "id": "resources" + }, + { + "name": "Nx and Angular CLI", + "id": "nx-and-cli", + "file": "angular/getting-started/nx-and-cli" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Add E2E Test", + "id": "02-add-e2e-test" + }, + { + "name": "3 - Display Todos", + "id": "03-display-todos" + }, + { + "name": "4 - Connect to API", + "id": "04-connect-to-api" + }, + { + "name": "5 - Add Node Application", + "id": "05-add-node-app" + }, + { + "name": "6 - Configure Proxy", + "id": "06-proxy" + }, + { + "name": "7 - Share Code", + "id": "07-share-code" + }, + { + "name": "8 - Create Libraries", + "id": "08-create-libs" + }, + { + "name": "9 - Dep Graph", + "id": "09-dep-graph" + }, + { + "name": "10 - Use Computation Caching", + "id": "10-computation-caching" + }, + { + "name": "11 - Test Affected Projects", + "id": "11-test-affected-projects" + }, + { + "name": "12 - Summary", + "id": "12-summary" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + }, + { + "name": "From Angular CLI", + "id": "migration-angular" + }, + { + "name": "From AngularJS", + "id": "migration-angularjs" + }, + { + "name": "Preserving Git Histories", + "id": "preserving-git-histories", + "file": "shared/migration/preserving-git-histories" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "CLI Overview", + "id": "overview", + "file": "angular/guides/cli-overview" + }, + { + "name": "Console", + "id": "console", + "file": "shared/console" + }, + { + "name": "generate", + "id": "generate", + "file": "angular/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "angular/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "angular/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "angular/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "angular/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "angular/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "angular/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "angular/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "angular/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "angular/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "angular/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "angular/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "angular/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "angular/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "angular/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "angular/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "angular/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "angular/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "angular/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "angular/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "angular/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "angular/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "angular/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "angular/cli/workspace-lint" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "angular/cli/workspace-schematic" + } + ] + }, + { + "name": "Plugins", + "id": "plugins", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Plugins Overview", + "id": "overview", + "file": "shared/plugins-overview" + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "id": "nrwl-workspace-overview", + "name": "Overview", + "searchResultsName": "@nrwl/workspace Overview", + "file": "shared/workspace-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "library", + "id": "library", + "file": "angular/api-workspace/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "angular/api-workspace/schematics/move" + }, + { + "name": "remove", + "id": "remove", + "file": "angular/api-workspace/schematics/remove" + }, + { + "name": "run-commands", + "id": "run-commands", + "file": "angular/api-workspace/schematics/run-commands" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "angular/api-workspace/schematics/workspace-schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "run-commands", + "id": "run-commands", + "file": "angular/api-workspace/builders/run-commands" + } + ] + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-web/schematics/application" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "angular/api-web/builders/build" + }, + { + "name": "dev-server", + "id": "dev-server", + "file": "angular/api-web/builders/dev-server" + }, + { + "name": "package", + "id": "package", + "file": "angular/api-web/builders/package" + } + ] + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-angular/schematics/application" + }, + { + "name": "downgrade-module", + "id": "downgrade-module", + "file": "angular/api-angular/schematics/downgrade-module" + }, + { + "name": "karma-project", + "id": "karma-project", + "file": "angular/api-angular/schematics/karma-project" + }, + { + "name": "karma", + "id": "karma", + "file": "angular/api-angular/schematics/karma" + }, + { + "name": "library", + "id": "library", + "file": "angular/api-angular/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "angular/api-angular/schematics/move" + }, + { + "name": "ngrx", + "id": "ngrx", + "file": "angular/api-angular/schematics/ngrx" + }, + { + "name": "stories", + "id": "stories", + "file": "angular/api-angular/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "angular/api-angular/schematics/storybook-configuration" + }, + { + "name": "upgrade-module", + "id": "upgrade-module", + "file": "angular/api-angular/schematics/upgrade-module" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "package", + "id": "package", + "file": "angular/api-angular/builders/package" + }, + { + "name": "ng packagr lite", + "id": "ng-packagr-lite", + "file": "angular/api-angular/builders/ng-packagr-lite" + }, + { + "name": "webpack-browser", + "id": "webpack-browser", + "file": "angular/api-angular/builders/webpack-browser" + } + ] + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-react/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "angular/api-react/schematics/component" + }, + { + "name": "component-cypress-spec", + "id": "component-cypress-spec", + "file": "angular/api-react/schematics/component-cypress-spec" + }, + { + "name": "component-story", + "id": "component-story", + "file": "angular/api-react/schematics/component-story" + }, + { + "name": "library", + "id": "library", + "file": "angular/api-react/schematics/library" + }, + { + "name": "redux", + "id": "redux", + "file": "angular/api-react/schematics/redux" + }, + { + "name": "stories", + "id": "stories", + "file": "angular/api-react/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "angular/api-react/schematics/storybook-configuration" + } + ] + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "jest", + "id": "jest", + "file": "angular/api-jest/builders/jest" + } + ] + } + ] + }, + { + "name": "cypress", + "id": "cypress", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/cypress Overview", + "file": "shared/cypress-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "cypress", + "id": "cypress", + "file": "angular/api-cypress/builders/cypress" + } + ] + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/storybook Overview", + "file": "angular/guides/storybook-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "configuration", + "id": "configuration", + "file": "angular/api-storybook/schematics/configuration" + }, + { + "name": "cypress-project", + "id": "cypress-project", + "file": "angular/api-storybook/schematics/cypress-project" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "angular/api-storybook/builders/build" + }, + { + "name": "storybook", + "id": "storybook", + "file": "angular/api-storybook/builders/storybook" + } + ] + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "eslint", + "id": "eslint", + "file": "angular/api-linter/builders/eslint" + }, + { + "name": "lint", + "id": "lint", + "file": "angular/api-linter/builders/lint" + } + ] + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-node/schematics/application" + }, + { + "name": "library", + "id": "library", + "file": "angular/api-node/schematics/library" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "angular/api-node/builders/build" + }, + { + "name": "execute", + "id": "execute", + "file": "angular/api-node/builders/execute" + }, + { + "name": "package", + "id": "package", + "file": "angular/api-node/builders/package" + } + ] + } + ] + }, + { + "name": "express", + "id": "express", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/express Overview", + "file": "shared/express-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-express/schematics/application" + } + ] + } + ] + }, + { + "name": "nest", + "id": "nest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nest Overview", + "file": "shared/nest-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-nest/schematics/application" + }, + { + "name": "class", + "id": "class", + "file": "angular/api-nest/schematics/class" + }, + { + "name": "controller", + "id": "controller", + "file": "angular/api-nest/schematics/controller" + }, + { + "name": "decorator", + "id": "decorator", + "file": "angular/api-nest/schematics/decorator" + }, + { + "name": "filter", + "id": "filter", + "file": "angular/api-nest/schematics/filter" + }, + { + "name": "gateway", + "id": "gateway", + "file": "angular/api-nest/schematics/gateway" + }, + { + "name": "guard", + "id": "guard", + "file": "angular/api-nest/schematics/guard" + }, + { + "name": "interceptor", + "id": "interceptor", + "file": "angular/api-nest/schematics/interceptor" + }, + { + "name": "interface", + "id": "interface", + "file": "angular/api-nest/schematics/interface" + }, + { + "name": "library", + "id": "library", + "file": "angular/api-nest/schematics/library" + }, + { + "name": "middleware", + "id": "middleware", + "file": "angular/api-nest/schematics/middleware" + }, + { + "name": "module", + "id": "module", + "file": "angular/api-nest/schematics/module" + }, + { + "name": "pipe", + "id": "pipe", + "file": "angular/api-nest/schematics/pipe" + }, + { + "name": "provider", + "id": "provider", + "file": "angular/api-nest/schematics/provider" + }, + { + "name": "resolver", + "id": "resolver", + "file": "angular/api-nest/schematics/resolver" + }, + { + "name": "service", + "id": "service", + "file": "angular/api-nest/schematics/service" + } + ] + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "angular/api-next/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "angular/api-next/schematics/component" + }, + { + "name": "page", + "id": "page", + "file": "angular/api-next/schematics/page" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "angular/api-next/builders/build" + }, + { + "name": "server", + "id": "server", + "file": "angular/api-next/builders/server" + }, + { + "name": "export", + "id": "export", + "file": "angular/api-next/builders/export" + } + ] + } + ] + }, + { + "name": "Nx Plugin", + "id": "nx-plugin", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nx-plugin Overview", + "file": "shared/nx-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "builder", + "id": "builder", + "file": "angular/api-nx-plugin/schematics/builder" + }, + { + "name": "migration", + "id": "migration", + "file": "angular/api-nx-plugin/schematics/migration" + }, + { + "name": "plugin", + "id": "plugin", + "file": "angular/api-nx-plugin/schematics/plugin" + }, + { + "name": "schematic", + "id": "schematic", + "file": "angular/api-nx-plugin/schematics/schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "e2e", + "id": "e2e", + "file": "angular/api-nx-plugin/builders/e2e" + } + ] + } + ] + } + ] + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Workspace Overview", + "id": "workspace-overview", + "file": "shared/workspace-overview" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "angular/guides/configuration" + }, + { + "name": "Builders", + "id": "builders", + "itemList": [ + { + "name": "Using Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "name": "Run Commands Builder", + "id": "run-commands-builder", + "file": "shared/running-custom-commands" + }, + { + "name": "Creating Custom Builders", + "id": "creating-custom-builders", + "file": "shared/tools-workspace-builders" + } + ] + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Schematics", + "id": "schematics", + "itemList": [ + { + "name": "Using Schematics", + "id": "using-schematics", + "file": "shared/using-schematics" + }, + { + "name": "Workspace Schematics", + "id": "workspace-schematics", + "file": "shared/tools-workspace-schematics" + } + ] + }, + { + "name": "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "Updating Nx", + "id": "update", + "file": "shared/update" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Rebuild Only What is Affected", + "id": "monorepo-affected", + "file": "shared/monorepo-affected" + }, + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + } + ] + }, + { + "name": "Modern Angular", + "id": "modern-angular", + "itemList": [ + { + "name": "Moving from Protractor to Cypress", + "id": "protractor-to-cypress", + "file": "angular/guides/modern-angular/protractor-to-cypress" + }, + { + "name": "Moving from Karma to Jest", + "id": "karma-to-jest", + "file": "angular/guides/modern-angular/karma-to-jest" + } + ] + }, + { + "name": "Using NgRx", + "id": "misc-ngrx" + }, + { + "name": "Using DataPersistence", + "id": "misc-data-persistence" + }, + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + }, + { + "name": "Nx 7 => Nx 8", + "id": "nx7-to-nx8" + }, + { + "name": "Upgrading AngularJS Applications", + "id": "misc-upgrade" + }, + { + "name": "Configuring Browser Support", + "id": "browser-support", + "file": "shared/guides/browser-support" + }, + { + "name": "Updating Nx", + "id": "updating-nx", + "file": "angular/guides/update" + }, + { + "name": "Running custom commands", + "id": "running-custom-commands", + "file": "angular/guides/running-custom-commands" + } + ] + }, + { + "name": "Examples", + "id": "examples", + "itemList": [ + { + "name": "Nx Micro-Frontend Example", + "id": "nx-examples", + "file": "shared/examples/nx-examples" + }, + { + "name": "Building Angular and React Applications Together With Nx", + "id": "react-and-angular", + "file": "angular/examples/react-and-angular" + }, + { + "name": "Using Apollo GraphQL", + "id": "apollo-angular", + "file": "angular/examples/apollo-angular" + } + ] + } + ] + }, + { + "id": "react", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Why Nx?", + "id": "why-nx", + "file": "react/getting-started/why-nx" + }, + { + "name": "Resources", + "id": "resources" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Add E2E Test", + "id": "02-add-e2e-test" + }, + { + "name": "3 - Display Todos", + "id": "03-display-todos" + }, + { + "name": "4 - Connect to API", + "id": "04-connect-to-api" + }, + { + "name": "5 - Add Node Application", + "id": "05-add-node-app" + }, + { + "name": "6 - Configure Proxy", + "id": "06-proxy" + }, + { + "name": "7 - Share Code", + "id": "07-share-code" + }, + { + "name": "8 - Create Libraries", + "id": "08-create-libs" + }, + { + "name": "9 - Dep Graph", + "id": "09-dep-graph" + }, + { + "name": "10 - Use Computation Caching", + "id": "10-computation-caching" + }, + { + "name": "11 - Test Affected Projects", + "id": "11-test-affected-projects" + }, + { + "name": "12 - Summary", + "id": "12-summary" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + }, + { + "name": "From CRA", + "id": "migration-cra" + }, + { + "name": "Preserving Git Histories", + "id": "preserving-git-histories", + "file": "shared/migration/preserving-git-histories" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "CLI Overview", + "id": "overview", + "file": "react/guides/cli-overview" + }, + { + "name": "Console", + "id": "console", + "file": "shared/console" + }, + { + "name": "generate", + "id": "generate", + "file": "react/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "react/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "react/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "react/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "react/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "react/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "react/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "react/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "react/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "react/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "react/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "react/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "react/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "react/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "react/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "react/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "react/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "react/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "react/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "react/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "react/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "react/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "react/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "react/cli/workspace-lint" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "react/cli/workspace-schematic" + } + ] + }, + { + "name": "Plugins", + "id": "plugins", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Plugins Overview", + "id": "overview", + "file": "shared/plugins-overview" + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "id": "nrwl-workspace-overview", + "name": "Overview", + "searchResultsName": "@nrwl/workspace Overview", + "file": "shared/workspace-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "library", + "id": "library", + "file": "react/api-workspace/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "react/api-workspace/schematics/move" + }, + { + "name": "remove", + "id": "remove", + "file": "react/api-workspace/schematics/remove" + }, + { + "name": "run-commands", + "id": "run-commands", + "file": "react/api-workspace/schematics/run-commands" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "react/api-workspace/schematics/workspace-schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "run-commands", + "id": "run-commands", + "file": "react/api-workspace/builders/run-commands" + } + ] + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-web/schematics/application" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "react/api-web/builders/build" + }, + { + "name": "dev-server", + "id": "dev-server", + "file": "react/api-web/builders/dev-server" + }, + { + "name": "package", + "id": "package", + "file": "react/api-web/builders/package" + } + ] + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-angular/schematics/application" + }, + { + "name": "downgrade-module", + "id": "downgrade-module", + "file": "react/api-angular/schematics/downgrade-module" + }, + { + "name": "karma-project", + "id": "karma-project", + "file": "react/api-angular/schematics/karma-project" + }, + { + "name": "karma", + "id": "karma", + "file": "react/api-angular/schematics/karma" + }, + { + "name": "library", + "id": "library", + "file": "react/api-angular/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "react/api-angular/schematics/move" + }, + { + "name": "ngrx", + "id": "ngrx", + "file": "react/api-angular/schematics/ngrx" + }, + { + "name": "stories", + "id": "stories", + "file": "react/api-angular/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "react/api-angular/schematics/storybook-configuration" + }, + { + "name": "upgrade-module", + "id": "upgrade-module", + "file": "react/api-angular/schematics/upgrade-module" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "package", + "id": "package", + "file": "react/api-angular/builders/package" + }, + { + "name": "ng packagr lite", + "id": "ng-packagr-lite", + "file": "react/api-angular/builders/ng-packagr-lite" + }, + { + "name": "webpack-browser", + "id": "webpack-browser", + "file": "react/api-angular/builders/webpack-browser" + } + ] + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-react/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "react/api-react/schematics/component" + }, + { + "name": "component-cypress-spec", + "id": "component-cypress-spec", + "file": "react/api-react/schematics/component-cypress-spec" + }, + { + "name": "component-story", + "id": "component-story", + "file": "react/api-react/schematics/component-story" + }, + { + "name": "library", + "id": "library", + "file": "react/api-react/schematics/library" + }, + { + "name": "redux", + "id": "redux", + "file": "react/api-react/schematics/redux" + }, + { + "name": "stories", + "id": "stories", + "file": "react/api-react/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "react/api-react/schematics/storybook-configuration" + } + ] + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "jest", + "id": "jest", + "file": "react/api-jest/builders/jest" + } + ] + } + ] + }, + { + "name": "cypress", + "id": "cypress", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/cypress Overview", + "file": "shared/cypress-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "cypress", + "id": "cypress", + "file": "react/api-cypress/builders/cypress" + } + ] + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/storybook Overview", + "file": "react/guides/storybook-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "configuration", + "id": "configuration", + "file": "react/api-storybook/schematics/configuration" + }, + { + "name": "cypress-project", + "id": "cypress-project", + "file": "react/api-storybook/schematics/cypress-project" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "react/api-storybook/builders/build" + }, + { + "name": "storybook", + "id": "storybook", + "file": "react/api-storybook/builders/storybook" + } + ] + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "eslint", + "id": "eslint", + "file": "react/api-linter/builders/eslint" + }, + { + "name": "lint", + "id": "lint", + "file": "react/api-linter/builders/lint" + } + ] + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-node/schematics/application" + }, + { + "name": "library", + "id": "library", + "file": "react/api-node/schematics/library" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "react/api-node/builders/build" + }, + { + "name": "execute", + "id": "execute", + "file": "react/api-node/builders/execute" + }, + { + "name": "package", + "id": "package", + "file": "react/api-node/builders/package" + } + ] + } + ] + }, + { + "name": "express", + "id": "express", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/express Overview", + "file": "shared/express-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-express/schematics/application" + } + ] + } + ] + }, + { + "name": "nest", + "id": "nest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nest Overview", + "file": "shared/nest-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-nest/schematics/application" + }, + { + "name": "class", + "id": "class", + "file": "react/api-nest/schematics/class" + }, + { + "name": "controller", + "id": "controller", + "file": "react/api-nest/schematics/controller" + }, + { + "name": "decorator", + "id": "decorator", + "file": "react/api-nest/schematics/decorator" + }, + { + "name": "filter", + "id": "filter", + "file": "react/api-nest/schematics/filter" + }, + { + "name": "gateway", + "id": "gateway", + "file": "react/api-nest/schematics/gateway" + }, + { + "name": "guard", + "id": "guard", + "file": "react/api-nest/schematics/guard" + }, + { + "name": "interceptor", + "id": "interceptor", + "file": "react/api-nest/schematics/interceptor" + }, + { + "name": "interface", + "id": "interface", + "file": "react/api-nest/schematics/interface" + }, + { + "name": "library", + "id": "library", + "file": "react/api-nest/schematics/library" + }, + { + "name": "middleware", + "id": "middleware", + "file": "react/api-nest/schematics/middleware" + }, + { + "name": "module", + "id": "module", + "file": "react/api-nest/schematics/module" + }, + { + "name": "pipe", + "id": "pipe", + "file": "react/api-nest/schematics/pipe" + }, + { + "name": "provider", + "id": "provider", + "file": "react/api-nest/schematics/provider" + }, + { + "name": "resolver", + "id": "resolver", + "file": "react/api-nest/schematics/resolver" + }, + { + "name": "service", + "id": "service", + "file": "react/api-nest/schematics/service" + } + ] + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "react/api-next/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "react/api-next/schematics/component" + }, + { + "name": "page", + "id": "page", + "file": "react/api-next/schematics/page" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "react/api-next/builders/build" + }, + { + "name": "server", + "id": "server", + "file": "react/api-next/builders/server" + }, + { + "name": "export", + "id": "export", + "file": "react/api-next/builders/export" + } + ] + } + ] + }, + { + "name": "Nx Plugin", + "id": "nx-plugin", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nx-plugin Overview", + "file": "shared/nx-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "builder", + "id": "builder", + "file": "react/api-nx-plugin/schematics/builder" + }, + { + "name": "migration", + "id": "migration", + "file": "react/api-nx-plugin/schematics/migration" + }, + { + "name": "plugin", + "id": "plugin", + "file": "react/api-nx-plugin/schematics/plugin" + }, + { + "name": "schematic", + "id": "schematic", + "file": "react/api-nx-plugin/schematics/schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "e2e", + "id": "e2e", + "file": "react/api-nx-plugin/builders/e2e" + } + ] + } + ] + } + ] + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Workspace Overview", + "id": "workspace-overview", + "file": "shared/workspace-overview" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "react/guides/configuration" + }, + { + "name": "Builders", + "id": "builders", + "itemList": [ + { + "name": "Using Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "name": "Run Commands Builder", + "id": "run-commands-builder", + "file": "shared/running-custom-commands" + }, + { + "name": "Creating Custom Builders", + "id": "creating-custom-builders", + "file": "shared/tools-workspace-builders" + } + ] + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Schematics", + "id": "schematics", + "itemList": [ + { + "name": "Using Schematics", + "id": "using-schematics", + "file": "shared/using-schematics" + }, + { + "name": "Workspace Schematics", + "id": "workspace-schematics", + "file": "shared/tools-workspace-schematics" + } + ] + }, + { + "name": "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "Updating Nx", + "id": "update", + "file": "shared/update" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Rebuild Only What is Affected", + "id": "monorepo-affected", + "file": "shared/monorepo-affected" + }, + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + } + ] + }, + { + "name": "Adding Images, Fonts, and Files", + "id": "adding-assets-react", + "file": "react/guides/adding-assets" + }, + { + "name": "Using Environment Variables", + "id": "environment-variables", + "file": "react/guides/environment-variables" + }, + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + }, + { + "name": "JavaScript and TypeScript", + "id": "js-and-ts", + "file": "react/guides/js-and-ts" + }, + { + "name": "Configuring Browser Support", + "id": "browser-support", + "file": "shared/guides/browser-support" + }, + { + "name": "Next.js projects with Nx", + "id": "nextjs", + "file": "react/guides/nextjs" + } + ] + }, + { + "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": "react/examples/react-nx" + }, + { + "name": "Using Apollo GraphQL", + "id": "apollo-react", + "file": "react/examples/apollo-react" + } + ] + } + ] + }, + { + "id": "node", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Why Nx?", + "id": "why-nx", + "file": "node/getting-started/why-nx" + }, + { + "name": "Resources", + "id": "resources" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Display Todos", + "id": "02-display-todos" + }, + { + "name": "3 - Share Code", + "id": "03-share-code" + }, + { + "name": "4 - Create Libraries", + "id": "04-create-libs" + }, + { + "name": "5 - Dep Graph", + "id": "05-dep-graph" + }, + { + "name": "6 - Use Computation Caching", + "id": "06-computation-caching" + }, + { + "name": "7 - Test Affected Projects", + "id": "07-test-affected-projects" + }, + { + "name": "8 - Summary", + "id": "08-summary" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "CLI Overview", + "id": "overview", + "file": "node/guides/cli-overview" + }, + { + "name": "Console", + "id": "console", + "file": "shared/console" + }, + { + "name": "generate", + "id": "generate", + "file": "node/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "node/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "node/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "node/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "node/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "node/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "node/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "node/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "node/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "node/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "node/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "node/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "node/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "node/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "node/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "node/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "node/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "node/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "node/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "node/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "node/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "node/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "node/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "node/cli/workspace-lint" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "node/cli/workspace-schematic" + } + ] + }, + { + "name": "Plugins", + "id": "plugins", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Plugins Overview", + "id": "overview", + "file": "shared/plugins-overview" + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "id": "nrwl-workspace-overview", + "name": "Overview", + "searchResultsName": "@nrwl/workspace Overview", + "file": "shared/workspace-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "library", + "id": "library", + "file": "node/api-workspace/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "node/api-workspace/schematics/move" + }, + { + "name": "remove", + "id": "remove", + "file": "node/api-workspace/schematics/remove" + }, + { + "name": "run-commands", + "id": "run-commands", + "file": "node/api-workspace/schematics/run-commands" + }, + { + "name": "workspace-schematic", + "id": "workspace-schematic", + "file": "node/api-workspace/schematics/workspace-schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "run-commands", + "id": "run-commands", + "file": "node/api-workspace/builders/run-commands" + } + ] + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-web/schematics/application" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "node/api-web/builders/build" + }, + { + "name": "dev-server", + "id": "dev-server", + "file": "node/api-web/builders/dev-server" + }, + { + "name": "package", + "id": "package", + "file": "node/api-web/builders/package" + } + ] + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-angular/schematics/application" + }, + { + "name": "downgrade-module", + "id": "downgrade-module", + "file": "node/api-angular/schematics/downgrade-module" + }, + { + "name": "karma-project", + "id": "karma-project", + "file": "node/api-angular/schematics/karma-project" + }, + { + "name": "karma", + "id": "karma", + "file": "node/api-angular/schematics/karma" + }, + { + "name": "library", + "id": "library", + "file": "node/api-angular/schematics/library" + }, + { + "name": "move", + "id": "move", + "file": "node/api-angular/schematics/move" + }, + { + "name": "ngrx", + "id": "ngrx", + "file": "node/api-angular/schematics/ngrx" + }, + { + "name": "stories", + "id": "stories", + "file": "node/api-angular/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "node/api-angular/schematics/storybook-configuration" + }, + { + "name": "upgrade-module", + "id": "upgrade-module", + "file": "node/api-angular/schematics/upgrade-module" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "package", + "id": "package", + "file": "node/api-angular/builders/package" + }, + { + "name": "ng packagr lite", + "id": "ng-packagr-lite", + "file": "node/api-angular/builders/ng-packagr-lite" + }, + { + "name": "webpack-browser", + "id": "webpack-browser", + "file": "node/api-angular/builders/webpack-browser" + } + ] + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-react/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "node/api-react/schematics/component" + }, + { + "name": "component-cypress-spec", + "id": "component-cypress-spec", + "file": "node/api-react/schematics/component-cypress-spec" + }, + { + "name": "component-story", + "id": "component-story", + "file": "node/api-react/schematics/component-story" + }, + { + "name": "library", + "id": "library", + "file": "node/api-react/schematics/library" + }, + { + "name": "redux", + "id": "redux", + "file": "node/api-react/schematics/redux" + }, + { + "name": "stories", + "id": "stories", + "file": "node/api-react/schematics/stories" + }, + { + "name": "storybook-configuration", + "id": "storybook-configuration", + "file": "node/api-react/schematics/storybook-configuration" + } + ] + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "jest", + "id": "jest", + "file": "node/api-jest/builders/jest" + } + ] + } + ] + }, + { + "name": "cypress", + "id": "cypress", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/cypress Overview", + "file": "shared/cypress-plugin" + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "cypress", + "id": "cypress", + "file": "node/api-cypress/builders/cypress" + } + ] + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "configuration", + "id": "configuration", + "file": "node/api-storybook/schematics/configuration" + }, + { + "name": "cypress-project", + "id": "cypress-project", + "file": "node/api-storybook/schematics/cypress-project" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "node/api-storybook/builders/build" + }, + { + "name": "storybook", + "id": "storybook", + "file": "node/api-storybook/builders/storybook" + } + ] + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "eslint", + "id": "eslint", + "file": "node/api-linter/builders/eslint" + }, + { + "name": "lint", + "id": "lint", + "file": "node/api-linter/builders/lint" + } + ] + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-node/schematics/application" + }, + { + "name": "library", + "id": "library", + "file": "node/api-node/schematics/library" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "node/api-node/builders/build" + }, + { + "name": "execute", + "id": "execute", + "file": "node/api-node/builders/execute" + }, + { + "name": "package", + "id": "package", + "file": "node/api-node/builders/package" + } + ] + } + ] + }, + { + "name": "express", + "id": "express", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/express Overview", + "file": "shared/express-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-express/schematics/application" + } + ] + } + ] + }, + { + "name": "nest", + "id": "nest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nest Overview", + "file": "shared/nest-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-nest/schematics/application" + }, + { + "name": "class", + "id": "class", + "file": "node/api-nest/schematics/class" + }, + { + "name": "controller", + "id": "controller", + "file": "node/api-nest/schematics/controller" + }, + { + "name": "decorator", + "id": "decorator", + "file": "node/api-nest/schematics/decorator" + }, + { + "name": "filter", + "id": "filter", + "file": "node/api-nest/schematics/filter" + }, + { + "name": "gateway", + "id": "gateway", + "file": "node/api-nest/schematics/gateway" + }, + { + "name": "guard", + "id": "guard", + "file": "node/api-nest/schematics/guard" + }, + { + "name": "interceptor", + "id": "interceptor", + "file": "node/api-nest/schematics/interceptor" + }, + { + "name": "interface", + "id": "interface", + "file": "node/api-nest/schematics/interface" + }, + { + "name": "library", + "id": "library", + "file": "node/api-nest/schematics/library" + }, + { + "name": "middleware", + "id": "middleware", + "file": "node/api-nest/schematics/middleware" + }, + { + "name": "module", + "id": "module", + "file": "node/api-nest/schematics/module" + }, + { + "name": "pipe", + "id": "pipe", + "file": "node/api-nest/schematics/pipe" + }, + { + "name": "provider", + "id": "provider", + "file": "node/api-nest/schematics/provider" + }, + { + "name": "resolver", + "id": "resolver", + "file": "node/api-nest/schematics/resolver" + }, + { + "name": "service", + "id": "service", + "file": "node/api-nest/schematics/service" + } + ] + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "application", + "id": "application", + "file": "node/api-next/schematics/application" + }, + { + "name": "component", + "id": "component", + "file": "node/api-next/schematics/component" + }, + { + "name": "page", + "id": "page", + "file": "node/api-next/schematics/page" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "node/api-next/builders/build" + }, + { + "name": "server", + "id": "server", + "file": "node/api-next/builders/server" + }, + { + "name": "export", + "id": "export", + "file": "node/api-next/builders/export" + } + ] + } + ] + }, + { + "name": "Nx Plugin", + "id": "nx-plugin", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/nx-plugin Overview", + "file": "shared/nx-plugin" + }, + { + "id": "schematics", + "name": "Schematics", + "itemList": [ + { + "name": "builder", + "id": "builder", + "file": "node/api-nx-plugin/schematics/builder" + }, + { + "name": "migration", + "id": "migration", + "file": "node/api-nx-plugin/schematics/migration" + }, + { + "name": "plugin", + "id": "plugin", + "file": "node/api-nx-plugin/schematics/plugin" + }, + { + "name": "schematic", + "id": "schematic", + "file": "node/api-nx-plugin/schematics/schematic" + } + ] + }, + { + "id": "builders", + "name": "Builders", + "itemList": [ + { + "name": "e2e", + "id": "e2e", + "file": "node/api-nx-plugin/builders/e2e" + } + ] + } + ] + } + ] + }, + { + "name": "Workspace", + "id": "workspace", + "itemList": [ + { + "name": "Overview", + "searchResultsName": "Workspace Overview", + "id": "workspace-overview", + "file": "shared/workspace-overview" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "node/guides/configuration" + }, + { + "name": "Builders", + "id": "builders", + "itemList": [ + { + "name": "Using Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "name": "Run Commands Builder", + "id": "run-commands-builder", + "file": "shared/running-custom-commands" + }, + { + "name": "Creating Custom Builders", + "id": "creating-custom-builders", + "file": "shared/tools-workspace-builders" + } + ] + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Schematics", + "id": "schematics", + "itemList": [ + { + "name": "Using Schematics", + "id": "using-schematics", + "file": "shared/using-schematics" + }, + { + "name": "Workspace Schematics", + "id": "workspace-schematics", + "file": "shared/tools-workspace-schematics" + } + ] + }, + { + "name": "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "Updating Nx", + "id": "update", + "file": "shared/update" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Rebuild Only What is Affected", + "id": "monorepo-affected", + "file": "shared/monorepo-affected" + }, + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + } + ] + }, + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + } + ] + } + ] + } +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/ng-packagr-lite.md new file mode 100644 index 0000000000..7e7f576f2e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/ng-packagr-lite.md @@ -0,0 +1,36 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/package.md new file mode 100644 index 0000000000..67a6e86156 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/package.md @@ -0,0 +1,46 @@ +# package + +Build and package an Angular library for publishing + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/webpack-browser.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/webpack-browser.md new file mode 100644 index 0000000000..0ce26b763e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/builders/webpack-browser.md @@ -0,0 +1,334 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +Type: `boolean` + +Log progress to the console while building. + +### rebaseRootRelativeCssUrls + +Default: `false` + +Type: `boolean` + +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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/10.4.13/node/api-angular/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/application.md new file mode 100644 index 0000000000..a895bddf45 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/10.4.13/node/api-angular/schematics/downgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/downgrade-module.md new file mode 100644 index 0000000000..83a9b97974 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup 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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma-project.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma-project.md new file mode 100644 index 0000000000..fb87bebaa3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing 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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma.md new file mode 100644 index 0000000000..fa41a5fe46 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/karma.md @@ -0,0 +1,23 @@ +# karma + +Add 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 +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/library.md new file mode 100644 index 0000000000..fb756b7a75 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/library.md @@ -0,0 +1,177 @@ +# library + +Create 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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### 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. 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/10.4.13/node/api-angular/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/move.md new file mode 100644 index 0000000000..835e09dc50 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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/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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/ngrx.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/ngrx.md new file mode 100644 index 0000000000..9d4a0f23dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## 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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/10.4.13/node/api-angular/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/stories.md new file mode 100644 index 0000000000..2c028bd632 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/stories.md @@ -0,0 +1,37 @@ +# 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/angular:stories ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g stories ... --dry-run +``` + +## Options + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/storybook-configuration.md new file mode 100644 index 0000000000..59170f1310 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a 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/angular:storybook-configuration ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g storybook-configuration ... --dry-run +``` + +## Options + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library + +### linter + +Default: `tslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/upgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/upgrade-module.md new file mode 100644 index 0000000000..093f05de01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-angular/schematics/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add 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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/node/api-cypress/builders/cypress.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-cypress/builders/cypress.md new file mode 100644 index 0000000000..00f4aed94a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-cypress/builders/cypress.md @@ -0,0 +1,126 @@ +# cypress + +Run Cypress e2e tests + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/10.4.13/node/api-express/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-express/schematics/application.md new file mode 100644 index 0000000000..c801960e6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-express/schematics/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/node/api-jest/builders/jest.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-jest/builders/jest.md new file mode 100644 index 0000000000..78e065f5ca --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-jest/builders/jest.md @@ -0,0 +1,222 @@ +# jest + +Run Jest unit tests + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/eslint.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/eslint.md new file mode 100644 index 0000000000..d1ecf36158 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/eslint.md @@ -0,0 +1,94 @@ +# eslint + +Run ESLint on a project + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/lint.md new file mode 100644 index 0000000000..c8e382a1d4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-linter/builders/lint.md @@ -0,0 +1,110 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/10.4.13/node/api-nest/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/application.md new file mode 100644 index 0000000000..cca4d44354 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest 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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/node/api-nest/schematics/class.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/class.md new file mode 100644 index 0000000000..919d78f9cc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/class.md @@ -0,0 +1,65 @@ +# class + +Run the 'class' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/controller.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/controller.md new file mode 100644 index 0000000000..6d876ec3ee --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/controller.md @@ -0,0 +1,65 @@ +# controller + +Run the 'controller' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/decorator.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/decorator.md new file mode 100644 index 0000000000..30c763bfe1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/decorator.md @@ -0,0 +1,65 @@ +# decorator + +Run the 'decorator' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/filter.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/filter.md new file mode 100644 index 0000000000..574c0bb7fa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/filter.md @@ -0,0 +1,65 @@ +# filter + +Run the 'filter' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/gateway.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/gateway.md new file mode 100644 index 0000000000..0c84025bed --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/gateway.md @@ -0,0 +1,65 @@ +# gateway + +Run the 'gateway' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/guard.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/guard.md new file mode 100644 index 0000000000..07c00cac00 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/guard.md @@ -0,0 +1,65 @@ +# guard + +Run the 'guard' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interceptor.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interceptor.md new file mode 100644 index 0000000000..ba3aff009e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interceptor.md @@ -0,0 +1,65 @@ +# interceptor + +Run the 'interceptor' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interface.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interface.md new file mode 100644 index 0000000000..6392eb510c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/interface.md @@ -0,0 +1,65 @@ +# interface + +Run the 'interface' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/library.md new file mode 100644 index 0000000000..5a96b01c79 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/library.md @@ -0,0 +1,159 @@ +# library + +Create a new nest 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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/node/api-nest/schematics/middleware.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/middleware.md new file mode 100644 index 0000000000..8f4f48344e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/middleware.md @@ -0,0 +1,65 @@ +# middleware + +Run the 'middleware' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/module.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/module.md new file mode 100644 index 0000000000..9d36d9e18e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/module.md @@ -0,0 +1,65 @@ +# module + +Run the 'module' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/pipe.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/pipe.md new file mode 100644 index 0000000000..49992338e2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/pipe.md @@ -0,0 +1,65 @@ +# pipe + +Run the 'pipe' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/provider.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/provider.md new file mode 100644 index 0000000000..6ea1995f14 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/provider.md @@ -0,0 +1,65 @@ +# provider + +Run the 'provider' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/resolver.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/resolver.md new file mode 100644 index 0000000000..35a7bf480c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/resolver.md @@ -0,0 +1,65 @@ +# resolver + +Run the 'resolver' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/service.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/service.md new file mode 100644 index 0000000000..78da4067aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nest/schematics/service.md @@ -0,0 +1,65 @@ +# service + +Run the 'service' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/build.md new file mode 100644 index 0000000000..c3ebe5d4ee --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/build.md @@ -0,0 +1,44 @@ +# build + +Build a Next.js app + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/export.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/export.md new file mode 100644 index 0000000000..37d3d14e2f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/export.md @@ -0,0 +1,28 @@ +# export + +Export a Next.js app. The exported application is located at dist/\$outputPath/exported. + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### 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/data-access-documents/src/data/10.4.13/node/api-next/builders/server.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/server.md new file mode 100644 index 0000000000..7076eb9897 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/builders/server.md @@ -0,0 +1,64 @@ +# server + +Serve a Next.js app + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/node/api-next/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/application.md new file mode 100644 index 0000000000..ec0c74b2b2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/application.md @@ -0,0 +1,123 @@ +# 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 + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style) + +### 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. + +### 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/data-access-documents/src/data/10.4.13/node/api-next/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/component.md new file mode 100644 index 0000000000..bb6cffb91e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/component.md @@ -0,0 +1,107 @@ +# 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/node/api-next/schematics/page.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/page.md new file mode 100644 index 0000000000..82ca21954e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-next/schematics/page.md @@ -0,0 +1,107 @@ +# 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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/node/api-node/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/build.md new file mode 100644 index 0000000000..907e79a73d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/build.md @@ -0,0 +1,162 @@ +# build + +Build a Node application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### buildLibsFromSource + +Default: `false` + +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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/execute.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/execute.md new file mode 100644 index 0000000000..b08dfb6134 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/execute.md @@ -0,0 +1,64 @@ +# execute + +Execute a Node application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/10.4.13/node/api-node/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/package.md new file mode 100644 index 0000000000..ff12624f41 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/builders/package.md @@ -0,0 +1,78 @@ +# package + +Package a Node library + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/node/api-node/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/schematics/application.md new file mode 100644 index 0000000000..5ed7f18cd4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/schematics/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/node/api-node/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/schematics/library.md new file mode 100644 index 0000000000..1320501c10 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-node/schematics/library.md @@ -0,0 +1,159 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/node/api-nx-plugin/builders/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/builders/e2e.md new file mode 100644 index 0000000000..0cf587ff28 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/builders/e2e.md @@ -0,0 +1,26 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/builder.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/builder.md new file mode 100644 index 0000000000..63c86c4e42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/builder.md @@ -0,0 +1,65 @@ +# builder + +Create a builder for an Nx Plugin + +## Usage + +```bash +nx generate builder ... +``` + +By default, Nx will search for `builder` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:builder ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g builder ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/builders/my-builder: + +```bash +nx g builder my-builder --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Builder description + +### name + +Type: `string` + +Builder name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/migration.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/migration.md new file mode 100644 index 0000000000..d8ebce862a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/migration.md @@ -0,0 +1,83 @@ +# 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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/plugin.md new file mode 100644 index 0000000000..f7bce6c1ba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/plugin.md @@ -0,0 +1,97 @@ +# 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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/schematic.md new file mode 100644 index 0000000000..dd34d31cdc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-nx-plugin/schematics/schematic.md @@ -0,0 +1,65 @@ +# schematic + +Create a schematic for an Nx Plugin + +## Usage + +```bash +nx generate schematic ... +``` + +By default, Nx will search for `schematic` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g schematic ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/schematics/my-schematic: + +```bash +nx g schematic my-schematic --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Schematic description + +### name + +Type: `string` + +Schematic name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/application.md new file mode 100644 index 0000000000..305c382e5d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/application.md @@ -0,0 +1,165 @@ +# 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/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. + +### 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. + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style). + +### 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/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-cypress-spec.md new file mode 100644 index 0000000000..58b52f635a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-story.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-story.md new file mode 100644 index 0000000000..35ef6ced9c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component-story.md @@ -0,0 +1,37 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component.md new file mode 100644 index 0000000000..8fe208e4ec --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/component.md @@ -0,0 +1,137 @@ +# component + +Create a 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/node/api-react/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/library.md new file mode 100644 index 0000000000..81cf8a607f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/library.md @@ -0,0 +1,173 @@ +# 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/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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### directory + +Alias(es): d + +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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/node/api-react/schematics/redux.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/redux.md new file mode 100644 index 0000000000..cda1e636d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/redux.md @@ -0,0 +1,67 @@ +# 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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/10.4.13/node/api-react/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/stories.md new file mode 100644 index 0000000000..69ae7ee393 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/stories.md @@ -0,0 +1,45 @@ +# 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 + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic. + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/storybook-configuration.md new file mode 100644 index 0000000000..d5a59afb47 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-react/schematics/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/build.md new file mode 100644 index 0000000000..163d3882c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/build.md @@ -0,0 +1,38 @@ +# build + +Build Storybook + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/storybook.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/storybook.md new file mode 100644 index 0000000000..6be3b85997 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/builders/storybook.md @@ -0,0 +1,82 @@ +# storybook + +Serve Storybook + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### port + +Default: `9009` + +Type: `number` + +Port to listen on. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/configuration.md new file mode 100644 index 0000000000..65eb7bc7c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/configuration.md @@ -0,0 +1,63 @@ +# configuration + +Add storybook configuration to a ui library + +## 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### 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` + +Library name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/cypress-project.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/cypress-project.md new file mode 100644 index 0000000000..ed108f43ac --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-storybook/schematics/cypress-project.md @@ -0,0 +1,49 @@ +# 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 + +### 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` + +Library name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/build.md new file mode 100644 index 0000000000..f59e8910ee --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/build.md @@ -0,0 +1,244 @@ +# build + +Build a application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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: `false` + +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. + +### crossOrigin + +Type: `string` + +The crossorigin attribute to use for generated javascript script tags. One of 'none' | 'anonymous' | 'use-credentials' + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/node/api-web/builders/dev-server.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/dev-server.md new file mode 100644 index 0000000000..96c14732a0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/dev-server.md @@ -0,0 +1,106 @@ +# dev-server + +Serve a web application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/node/api-web/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/package.md new file mode 100644 index 0000000000..a1ce5b616d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/builders/package.md @@ -0,0 +1,114 @@ +# package + +Package a library + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/10.4.13/node/api-web/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/schematics/application.md new file mode 100644 index 0000000000..914d89a1c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-web/schematics/application.md @@ -0,0 +1,103 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/10.4.13/node/api-workspace/builders/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/builders/run-commands.md new file mode 100644 index 0000000000..5ab1354885 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/builders/run-commands.md @@ -0,0 +1,220 @@ +# run-commands + +Run any custom commands with Nx + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/node/guides/cli. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/library.md new file mode 100644 index 0000000000..681c06659f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/library.md @@ -0,0 +1,133 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/move.md new file mode 100644 index 0000000000..8f7f38a34e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/move.md @@ -0,0 +1,65 @@ +# 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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/remove.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/remove.md new file mode 100644 index 0000000000..a83d277938 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/remove.md @@ -0,0 +1,71 @@ +# 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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/run-commands.md new file mode 100644 index 0000000000..6ab77cfeba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/run-commands.md @@ -0,0 +1,67 @@ +# 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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/workspace-schematic.md new file mode 100644 index 0000000000..d90b6755c4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/api-workspace/schematics/workspace-schematic.md @@ -0,0 +1,39 @@ +# workspace-schematic + +Generates a workspace schematic + +## Usage + +```bash +nx generate workspace-schematic ... +``` + +By default, Nx will search for `workspace-schematic` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/workspace:workspace-schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g workspace-schematic ... --dry-run +``` + +## Options + +### name + +Type: `string` + +Schematic name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/builders.json b/nx-dev/data-access-documents/src/data/10.4.13/node/builders.json new file mode 100644 index 0000000000..722846ec08 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/builders.json @@ -0,0 +1,14 @@ +[ + "angular", + "cypress", + "express", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/node/cli/affected-build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-build.md new file mode 100644 index 0000000000..76dc8d0795 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-build.md @@ -0,0 +1,137 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/node/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-e2e.md new file mode 100644 index 0000000000..f6a9518562 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-e2e.md @@ -0,0 +1,125 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/node/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/node/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-lint.md new file mode 100644 index 0000000000..ebf0491368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-lint.md @@ -0,0 +1,125 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/node/cli/affected-test.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-test.md new file mode 100644 index 0000000000..663ec95368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected-test.md @@ -0,0 +1,125 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/node/cli/affected.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected.md new file mode 100644 index 0000000000..874b43a5c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/affected.md @@ -0,0 +1,147 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/node/cli/build.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/10.4.13/node/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/e2e.md new file mode 100644 index 0000000000..1fdb16dc1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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 & autmatically 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/data-access-documents/src/data/10.4.13/node/cli/format-check.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/node/cli/format-write.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/node/cli/generate.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/generate.md new file mode 100644 index 0000000000..033fcfd871 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/generate.md @@ -0,0 +1,93 @@ +# generate + +Runs a schematic that generates and/or modifies files based on a schematic from a collection. + +## Usage + +```bash +nx generate +``` + +```bash +nx g +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 schematics in the default collection. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/10.4.13/node/cli/list.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/list.md new file mode 100644 index 0000000000..09742dbc9b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +List the plugins installed in the current workspace: + +```bash +nx list +``` + +List the schematics and builders 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/migrate.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/node/cli/print-affected.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/10.4.13/node/cli/report.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run-many.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run-many.md new file mode 100644 index 0000000000..11f3319105 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run-many.md @@ -0,0 +1,101 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/node/cli/serve.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/10.4.13/node/cli/test.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/10.4.13/node/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/cli/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/workspace-schematic.md new file mode 100644 index 0000000000..1935090762 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/cli/workspace-schematic.md @@ -0,0 +1,29 @@ +# workspace-schematic + +Runs a workspace schematic from the tools/schematics directory + +## Usage + +```bash +nx workspace-schematic +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### list-schematics + +List the available workspace-schematics + +### name + +The name of your schematic` + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/resources.md b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/resources.md new file mode 100644 index 0000000000..aff14c088b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/resources.md @@ -0,0 +1,118 @@ +# Resources + +## 45-Minute Walkthrough + + + +## Quick Introductions (10 minutes) + + + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## Resources + +### Talks + +- [React Development At Scale (React Vancouver Virtual Meetup)](https://youtu.be/ZGXuzVipe1U?t=3721), Jack Hsu (May 27, 2020) + +- [Scalable React Development (React Summit Remote Edition)](https://www.youtube.com/watch?v=Lr-u2ALSEQg), Jason Jean (April 17, 2020) + Slides: [https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/](https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/) + +- [Beyond Basics: Scaling Development across Large Teams (Angular Rome Meetup online)](https://docs.google.com/presentation/d/1zEgeppole9avhrvV6Zmpmk-L1W9-6JsHbnjaJwBigtQ/edit?usp=sharing), Juri Strumpflohner (April 2, 2020) + +- [Develop like Google, Microsoft, and Facebook with Nx - Dev Nexus](https://prezi.com/view/BVhl92reqg7cnhvv6hhH/), Jason Jean (February 18, 2020) + +- [Enhancing the workspace with Custom Builders - AngularToronto](https://www.youtube.com/watch?v=M1Bk_O49n94), Benjamin Cabanes (February 18, 2020) + +- [Advanced Nx - Angular Air](https://www.youtube.com/watch?v=pcTSDMid-aE), Isaac Mann (February 5th, 2020) + +- [Teach Me Anything - HackFlix](https://www.youtube.com/watch?v=WRmj4JwfoMs) - Isaac Mann (January 9th, 2020) + +* [E2E Testing at Half the Cost - NG-BE 2019](https://www.youtube.com/watch?v=C88th0SbepE), Isaac Mann (Dev 10, 2019) + +* [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +* [Building Large Angular Apps - ngBucharest](https://www.youtube.com/watch?v=bKhyTeTCf7M), Isaac Mann (March 30, 2019) + + - Slides: [https://prezi.com/view/jglXvEfeqnjEr4l2L11h/](https://prezi.com/view/jglXvEfeqnjEr4l2L11h/) + +* [Modern Development with Angular CLI & Nrwl Nx](https://www.youtube.com/watch?v=tE8sUAfKI3g), Victor Savkin at ngAtlanta (Feb 5, 2019) + +* [Supercharging the Angular CLI](https://www.youtube.com/watch?v=bMkKz8AedHc) - ngVikings, James Henry (March 10, 2018) + +* [Hands on Full Stack development with Nx and Bazel](https://www.youtube.com/watch?v=1KDDIhcQORM) - ngConf, Alex Eagle, Torgeir Helgevold (April 19, 2018) + +* [Angular at Large Organizations](https://www.youtube.com/watch?v=piQ0EZhtus0) - ngConf, Victor Savkin(April 20, 2018) + +* [Building Large Angular Apps Successfully with Nx - AngularNYC Meetup](https://youtu.be/Jwv3wRZ3BTM), Jason Jean (December 19, 2018) + +- [Nx: The New Way to Build Enterprise Angular Apps](https://www.youtube.com/watch?v=xo-1SDmvM8Y) - Angular Mix, Jeff Cross & Victor Savkin (October 11, 2017) + +### Podcasts and Shows + +- [Nx Plugins - ngHouston](https://youtu.be/bydqr-Yxsu8), Wes Grimes and Jon Cammisuli (April 8 2020) + +- [Apollo GQL, Angular & Nx - ngHouston](https://youtu.be/bydqr-Yxsu8), Philip Fulcher (Feb 26, 2020) + +- [Teach Me Anything - With Isaac Mann from Nrwl](https://youtu.be/WRmj4JwfoMs), Isaac Mann (Jan 9, 2020) + +- [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +- [React Roundup: Nx and Monorepos](https://player.fm/series/react-round-up/rru-081-nx-and-monorepos-with-jeffrey-cross-and-victor-savkin), Victor Savkin (Oct 1, 2019) + +- [Nx and Angular CLI - Adventures in Angular](https://devchat.tv/adv-in-angular/aia-254-nx-and-angular-cli-with-brandon-roberts/), Brandon Roberts (Aug 27th 2019) + +- [ngHouston: NX Demo](https://www.youtube.com/watch?v=E_UlU2Yv4G0) (Dec 7, 2017) + +- [ngAir 140: Nx for Enterprise Angular Development](https://www.youtube.com/watch?v=qYNiOKDno_I), Victor Savkin (Dec 12, 2017) + +### Nx Demo & Tutorial Videos + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (Angular)](https://youtu.be/h5FIGDn5YM0) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Nx Console - A Must-Have Visual Studio Code Extension for Angular Developers](https://youtu.be/IIetmfgozgI) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +### Books amd Blogs + +- [Nx blog posts](https://blog.nrwl.io/nx/home) + +- [Angular Enterprise Monorepo Patterns Book (free)](https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book?utm_campaign=Book%3A%20Monorepo%20Patterns%2C%20Jan%202019&utm_source=Github&utm_medium=Banner%20Ad) + +* [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +* [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +- [Tiny Angular application projects in Nx workspaces](https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/#peer-reviewers--30/) (March 2020) + +### Misc + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [xplat - Cross-platform tools for Nx workspaces](https://nstudio.io/xplat/) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/why-nx.md b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/why-nx.md new file mode 100644 index 0000000000..55fc46217e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/getting-started/why-nx.md @@ -0,0 +1,61 @@ +# Why Nx? + +Nx is the preeminent toolkit for Monorepo development, which helps you to build software smarter and faster. With Nx you can build full-stack applications with your preferred framework, integrate with modern tools you’re probably already using, and reinforce best practices for your entire development team or enterprise. Use Nx to build software at scale, the better way. + +- Out of the box integration with Cypress, Jest, Typescript, Prettier + more +- Has a growing ecosystem, and a community plugin market +- Many leading enterprises are already using Nx to build the software you know and love + +## 10-Minute Nx Overview + + + +## Why Monorepos? + +A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them. + +### What are the benefits of a monorepo? + +- **Shared code** - Keep your code DRY across your entire organization. Reuse validation code, UI components and types across the code base. Reuse code between the backend and the frontend. +- **Atomic changes** - Change a server API and modify the clients that consume that API in the same commit. You can change a button component in a shared library and the applications that use that component in the same commit. This saves the pain of trying to coordinate commits across multiple repositories. +- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe. +- **Single set of dependencies** - Use a single version of third party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3 year old version of a framework library or an old version of webpack. + +## Why Not Code Collocation? + +A naive implementation of a monorepo is simply code collocation - placing all the code from multiple repositories into the same repo without adequate tooling to coordinate everything. What problems arise from code collocation? + +- **Running unnecessary tests** - In order to ensure nothing was broken by a change, all tests in the entire repository need to be run - even code in projects that are unrelated to the actual change. +- **No code boundaries** - A developer from another team can change code in your project, causing bugs or inconsistencies. Or worse, another team can use code that you intended for private use - forcing you to never change that code for fear of breaking their application. +- **Inconsistent tooling** - Each project uses its own set of commands for running tests, building, serving, etc. This makes it very difficult to move from project to project. + +Tools like Lerna and Yarn Workspaces help optimize the installation of node modules, but they **do not** enable Monorepo-style development. In other words, they solve an orthogonal problem and sometimes can be used in combination with Nx. Read more on it [here](https://blog.nrwl.io/why-you-should-switch-from-lerna-to-nx-463bcaf6821). + +## Nx Can Help + +Nx provides tools to give you the benefits of a monorepo without the drawbacks of simple code collocation. + +### Scaling Your Repo + +- **Faster Command Execution** - Builders allow for consistent commands to test, serve, build, lint, etc, each project. [Nx’s affected command]() helps run commands only on code that is affected by the current change. Nx provides local and distributed caching of builder commands so when someone on your team runs a command, everyone else will use their artifacts to speed up their own command executions, often bringing them down from minutes to seconds. This, in combination with support for distributed and incremental builds helps you scale your development to massive applications and repositories. + +### Scaling Your Organization + +- **Controlled Code Sharing** - You can define libraries with specific enforced APIs and put rules in place to define how those libraries can depend on each other. A CODEOWNERS file can be used to restrict who is allowed to change files in each project. +- **Consistent Code Generation** - Schematics allow you to automate code creation and modification tasks. Instead of writing a 7 step guide in a readme file, you can create a schematic to prompt the developer for inputs and then modify the code directly. Nrwl provides plugins which contain useful builders and schematics for a lot of popular tools. Also, there is a growing number of community provided plugins. +- **Accurate Architecture Diagram** - Most architecture diagrams are wrong the moment they are written down. And every diagram becomes out of date as soon as the code changes. Since Nx understands your code, it can generate an up-to-date and accurate diagram of how projects depend on each other. And for cases where dependencies are not explicit in the code, you can manually tell Nx about project dependencies. + +## Next Steps + +**Learn Nx Fundamentals:** + +- [Interactive Nx Tutorial](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) +- [45-Minute Walkthrough](https://www.youtube.com/watch?v=jCf92IyR-GE) + +**Dive Deep:** + +- [Nx CLI](/{{framework}}/cli/overview) +- [Configuration Files](/{{framework}}/workspace/configuration) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/10.4.13/node/guides/cli-overview.md new file mode 100644 index 0000000000..d74b4a436c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/guides/cli-overview.md @@ -0,0 +1,267 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/node`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called schematics. Schematics provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/node:application myapp +``` + +The `@nrwl/node` package contains a collection of schematics, with `application` being the one used in this example. The Nx CLI applies the schematic to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the schematic. + +```sh +nx generate @nrwl/node:application myapp --style=scss +``` + +You can preview the changes a schematic makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the schematic. + +**Generate command:** + +`nx generate` runs schematics to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[schematic-name] [options]` + Example: `nx generate @nrwl/node:library my-node-lib` + +## Running Tasks + +The Nx CLI uses builders to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +A builder is a function that uses the Architect API to perform a complex process such as "build", "test", or "lint". + +You can configure the builders in `workspace.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "architect": { + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` builder, and the `test` target uses `@nrwl/jest:jest`. Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # producttion configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any builders you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx affected --target=build --prod +``` + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/guides/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/node/guides/configuration.md new file mode 100644 index 0000000000..4b44b8039c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/guides/configuration.md @@ -0,0 +1,370 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## workspace.json + +The `workspace.json` configuration file contains information about the targets and schematics. Let's look at the following example: + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/node:build", + "outputs": ["dist/apps/myapp"], + "options": { + "outputPath": "dist/packages/myapp", + "main": "packages/myapp/src/main.ts", + "tsConfig": "packages/myapp/tsconfig.app.json", + "assets": ["packages/myapp/src/assets"] + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "builder": "@nrwl/node:execute", + "options": { + "buildTarget": "myapp:build" + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": { + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + }, + "build": { + "builder": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/node" + }, + "schematics": { + "@nrwl/node:library": { + "js": true + } + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": {} + } +} +``` + +- `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'. +- `architect` configures all the targets which define what tasks you can run against the library. + +> Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular. + +### Targets + +Let's look at the simple architect target: + +```json +{ + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js" + } + } +} +``` + +**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 run mylib:mytest`. + +**Builder** + +The `builder` 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 builder named `jest` and invoke it with the options. + +**Options** + +The `options` provides a map of values that will be passed to the builder. 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 builder: + +```json +{ + "jestConfig": "libs/mylib/another-jest.config.js" +} +``` + +**Outputs** + +The `outputs` property lists the folders the builder will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "builder": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "builder": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + }, + "configurations": { + "production": { + "packageJson": "libs/mylib/package.prod.json" + } + } +} +``` + +You can select a configuration like this: `nx build mylib --configuration=production` or `nx run mylib:build:configuration=production`. + +The following show how the builder options get constructed: + +```bash +require(`@nrwl/jest`).builders['jest']({...options, ...selectedConfiguration, ...commandLineArgs}}) // Pseudocode +``` + +The selected configuration adds/overrides the default options, and the provided command line args add/override the configuration options. + +### Schematics + +You can configure default schematic options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. + +```json +{ + "schematics": { + "@nrwl/node:library": { + "buildable": true + } + } +} +``` + +You can also do it on the project level: + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "schematics": { + "@nrwl/node:lib": { + "moreOptions": true + } + }, + "architect": {} + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/node:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/node" + } +} +``` + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "workspace.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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 dependencies between shared files and projects 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` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/schematics.json b/nx-dev/data-access-documents/src/data/10.4.13/node/schematics.json new file mode 100644 index 0000000000..ae621ac6e8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/schematics.json @@ -0,0 +1,14 @@ +[ + "angular", + "cypress", + "express", + "jest", + "nest", + "next", + "node", + "nx-plugin", + "react", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/01-create-application.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/01-create-application.md new file mode 100644 index 0000000000..619991a46d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/01-create-application.md @@ -0,0 +1,127 @@ +# Step 1: Create Application + +## Video of this Lesson + + + +In this tutorial you will use Nx to build a server application out of common libraries using modern technologies. + +## Create a New Workspace + +**Start by creating a new workspace.** + +```shell script +yarn create nx-workspace + +? Workspace name (e.g., org name) myorg +? What to create in the new workspace nest +? Application name todos +``` + +```treeview +myorg/ +├── README.md +├── apps/ +│   └── todos/ +│   ├── jest.config.js +│   ├── src/ +│   │   ├── app/ +│   │   │   ├── app.controller.spec.ts +│   │   │   ├── app.controller.ts +│   │   │   ├── app.module.ts +│   │   │   ├── app.service.spec.ts +│   │   │   └── app.service.ts +│   │   ├── assets/ +│   │   ├── environments/ +│   │   │   ├── environment.prod.ts +│   │   │   └── environment.ts +│   │   └── main.ts +│   ├── tsconfig.app.json +│   ├── tsconfig.json +│   └── tsconfig.spec.json +├── tools/ +│   ├── schematics +│   └── tsconfig.tools.json +├── jest.config.js +├── libs +├── nx.json +├── package.json +├── tsconfig.base.json +└── workspace.json +``` + +The generate command added one project to our workspace: + +- A Nest application + +## Note on the Nx CLI + +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: + +```shell script +npm install -g nx +``` + +or + +```shell script +yarn global add nx +``` + +Or you can prepend every command with `npm run`: + +```bash +npm run nx -- serve todos +``` + +or + +```bash +yarn nx serve todos +``` + +## Workspace.json, Targets, Builders + +You configure your workspaces in `workspace.json`. This file contains the workspace projects with their architect targets. For instance, `todos` has the `build`, `serve`, `lint`, and `test` targets. This means that you can run `nx build todos`, `nx serve todos`, etc.. + +Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +**Why not use shell scripts and npm scripts directly?** + +There are a lot of advantages to providing additional metadata to the build tool. For instance, you can introspect targets. `nx serve todos --help` results in: + +```shell script +nx run todos:serve [options,...] + +Options: + --buildTarget The target to run to build you the app + --waitUntilTargets The targets to run to before starting the node app (default: ) + --host The host to inspect the process on (default: localhost) + --port The port to inspect the process on. Setting port to 0 will assign random free ports to all forked processes. + --watch Run build when files change (default: true) + --inspect Ensures the app is starting with debugging (default: inspect) + --runtimeArgs Extra args passed to the node process (default: ) + --args Extra args when starting the app (default: ) + --help Show available options for project target. +``` + +It helps with good editor integration (see [VSCode Support](https://nx.dev/node/cli/console)). + +But, most importantly, it provides a holistic dev experience regardless of the tools used, and enables advanced build features like distributed computation caching and distributed builds). + +## Serve the newly created application + +Now that the application is set up, run it locally via: + +```shell script +nx serve todos +``` + +!!!!! +Open http://localhost:3333/api in the browser. What do you see? +!!!!! +Page saying "{"message":"Welcome to todos!"}" +Page saying "This is Nest app built with Nx!" +404 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/02-display-todos.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/02-display-todos.md new file mode 100644 index 0000000000..3b145b56c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/02-display-todos.md @@ -0,0 +1,156 @@ +# Step 2: Display todos + +## Video of this Lesson + + + +Great! We now have a server application set up to show some data when going to the `/api` route. + +Next, we're going to add a new service, and set up some server side templates. + +## Creating a todos service + +With Nx, we have the ability to scaffold out new code for our application. Let's create a Todos service and populate some todos! + +**Run `nx generate @nrwl/nest:service todo --project todos --directory app` to generate our new service** + +```shell script +$ nx generate @nrwl/nest:service todo --project todos --directory app +CREATE apps/todos/src/app/todo/todo.service.spec.ts (453 bytes) +CREATE apps/todos/src/app/todo/todo.service.ts (89 bytes) +UPDATE apps/todos/src/app/app.module.ts (318 bytes) +``` + +> Services are not the only things that the `@nrwl/nest` plugin can create. Run `nx list @nrwl/nest` to see other capabilities that the plugin provides. + +Open the newly created file in `apps/todos/src/app/todo/todo.service.ts` and paste the following code: + +```typescript +import { Injectable } from '@nestjs/common'; + +export type Todo = { + message: string; + done: boolean; +}; + +const todos: Todo[] = [ + { message: 'Take out trash', done: false }, + { message: 'Continue using Nx', done: false }, +]; + +@Injectable() +export class TodosService { + getTodos(): Todo[] { + return todos; + } +} +``` + +> Usually services should call some kind of data source (like a database or even a file) but for our tutorial, we'll just populate todos manually. + +We now have our Todos service ready! + +## Install template engine + +In order to render some views, we'll need to install a template engine: + +```shell script +yarn add hbs +``` + +or + +```shell script +npm install --save hbs +``` + +Once the installation process is complete, we need to configure the `main.ts` file with the following code: + +```typescript +import { Logger } from '@nestjs/common'; +import { NestFactory } from '@nestjs/core'; +import { NestExpressApplication } from '@nestjs/platform-express'; +import { join } from 'path'; + +import { AppModule } from './app/app.module'; + +async function bootstrap() { + const app = await NestFactory.create(AppModule); + + app.setBaseViewsDir(join(__dirname, 'assets', 'views')); + app.setViewEngine('hbs'); + + const port = process.env.PORT || 3333; + await app.listen(port, () => { + Logger.log('Listening at http://localhost:' + port); + }); +} + +bootstrap(); +``` + +We added configuration for setting up the view engine, and removed the `globalPrefix` option. + +## Template rendering + +Under the `assets` directory of the todo's project, we'll create a `views` directory with an `index.hbs` file inside with the following content: + +```handlebars + + + + + App + + + +
    + {{#each todos}} +
  • {{message}}
    • + {{/each}} +
+ + +``` + +Next, we'll update the `app.controller.ts` file with the following: + +```typescript +import { Controller, Get, Render } from '@nestjs/common'; + +import { AppService } from './app.service'; +import { TodosService } from './todos/todos.service'; + +@Controller() +export class AppController { + constructor( + private readonly appService: AppService, + private todosService: TodosService + ) {} + + @Get('api') + getData() { + return this.todosService.getTodos(); + } + + @Get() + @Render('index') + root() { + return { + todos: this.getData(), + }; + } +} +``` + +We changed the `@Get` decorator for the `getData` function to point to the `api` route. We also changed this to call the `todosService.getTodos()` method. \ +Then we added the `root` function which renders the `index` file from our `views` directory. + +> The serve process should still be running. If it isn't, restart the process with `nx serve todos` + +!!!!! +Open http://localhost:3333 in the browser. What do you see? +!!!!! +Page saying "Welcome to todos!" +Page saying "{"message":"Welcome to todos!"}" +404 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/03-share-code.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/03-share-code.md new file mode 100644 index 0000000000..2cc3410e83 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/03-share-code.md @@ -0,0 +1,82 @@ +# Step 3: Share Code + +## Video of this Lesson + + + +Awesome! The application is working as expected! + +Next, let's work on refactoring a bit. What we're planning to do is move the `Todo` type to it's own library. This is important if we want to share the type between multiple applications, without having to duplicate the same type everywhere. + +**Run the following generator to create a library:** + +```bash +nx g @nrwl/workspace:lib data +``` + +The result should look like this: + +```treeview +myorg/ +├── apps/ +│   └── todos/ +├── libs/ +│   └── data/ +│      ├── src/ +│      │   ├── lib/ +│ │ │ └── data.ts +│      │   └── index.ts +│      ├── jest.config.js +│      ├── tsconfig.lib.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.base.json +``` + +**Copy the type into `libs/data/src/lib/data.ts`.** + +```typescript +export type Todo = { + message: string; + done: boolean; +}; +``` + +### 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 recognised. This needs to be done **every time a new workspace library is added**. + +Use the command pallette with a `*.ts` file open and choose `Restart TS Server`. + +## Refactor the Todos Service + +**Now update `apps/todos/src/app/todos/todos.service.ts` to import the type:** + +```typescript +import { Injectable } from '@nestjs/common'; +import { Todo } from '@myorg/data'; + +const todos: Todo[] = [ + { message: 'Take out trash', done: false }, + { message: 'Continue using Nx', done: false }, +]; + +@Injectable() +export class TodosService { + getTodos(): Todo[] { + return todos; + } +} +``` + +Every time you add a new library, you have to restart `nx serve`. **So restart `nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between Nx applications and libraries +Between Nx applications +Between Nx libraries diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/04-create-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/04-create-libs.md new file mode 100644 index 0000000000..8e341993a9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/04-create-libs.md @@ -0,0 +1,95 @@ +# Step 4: Create Libraries + +## Video of this Lesson + + + +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. + +## Controller Libraries + +To illustrate how useful libraries can be, create a new Auth library with a controller. + +Run + +```bash +nx g @nrwl/nest:lib auth --controller +``` + +> We added the `--controller` flag here to generate a controller along with the library scaffolding. + +You should see the following: + +```treeview +myorg/ +├── apps/ +│ └── todos/ +├── libs/ +│ ├── auth/ +│ │ ├── jest.config.js +│ │ ├── src/ +│ │ │ ├── index.ts +│ │ │ └── lib/ +│ │ │ ├── auth.controller.spec.ts +│ │ │ ├── auth.controller.ts +│ │ │ └── auth.module.ts +│ │ ├── tsconfig.json +│ │ ├── tsconfig.lib.json +│ │ └── tsconfig.spec.json +│ └── data/ +├── tools/ +├── nx.json +├── package.json +├── tsconfig.base.json +└── workspace.json +``` + +Modify the `libs/auth/src/lib/auth.controller.ts` file like this: + +```typescript +import { Controller, Get } from '@nestjs/common'; + +@Controller('auth') +export class AuthController { + @Get() + auth() { + return { + authenticated: true, + }; + } +} +``` + +> In code destined for production, we would actually have a proper authentication check here. + +## Use the new Library + +**Now import `AuthModule` into `apps/todos/src/app/app.module.ts`.** + +```typescript +import { Module } from '@nestjs/common'; + +import { AppController } from './app.controller'; +import { AppService } from './app.service'; +import { TodosService } from './todos/todos.service'; +import { AuthModule } from '@myorg/auth'; + +@Module({ + imports: [AuthModule], + controllers: [AppController], + providers: [AppService, TodosService], +}) +export class AppModule {} +``` + +**Restart `nx serve todos` then go to http://localhost:3333/auth. You should see `{ authenticated: true }`** + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +workspace.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/05-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/05-dep-graph.md new file mode 100644 index 0000000000..3047bedf2d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/05-dep-graph.md @@ -0,0 +1,18 @@ +# Step 5: Dep Graph + +## Video of this Lesson + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "nx dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/06-computation-caching.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/06-computation-caching.md new file mode 100644 index 0000000000..52431ba203 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/06-computation-caching.md @@ -0,0 +1,82 @@ +# Step 6: Computation Caching + +## Video of this Lesson + + + +Nx has built-in computation caching, which drastically improves the performance of the commands. + +**To see it in action, run `nx build todos`:** + +```bash +> nx run todos:build +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: 51f23143c450a9f931a7 +Built at: 09/04/2020 4:03:20 PM +Entrypoint main = main.js main.js.map +chunk {main} main.js, main.js.map (main) 4.17 KiB [entry] [rendered] +``` + +**Now, run `nx build todos` again, and you will see the results appearing instantly:** + +```bash +> nx run todos:build + +> NX NOTE Cached Output: + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: 51f23143c450a9f931a7 +Built at: 09/04/2020 4:03:20 PM +Entrypoint main = main.js main.js.map +chunk {main} main.js, main.js.map (main) 4.17 KiB [entry] [rendered] +``` + +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. + +## --with-deps + +Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> nx run data:lint + +Linting "data"... + +All files pass linting. + + +> nx run auth:lint + +Linting "auth"... + +All files pass linting. + + +> nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `nx lint auth --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 1 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/07-test-affected-projects.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/07-test-affected-projects.md new file mode 100644 index 0000000000..15833a3df8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/07-test-affected-projects.md @@ -0,0 +1,81 @@ +# Step 7: Test Affected Projects + +## Video of this Lesson + + + +In addition to supporting computation caching, Nx can scale your development by doing code change analysis to see what apps or libraries are affected by a particular pull request. + +**Commit all the changes in the repo**: + +```bash +git add . +git commit -am 'init' +git checkout -b testbranch +``` + +**Open `libs/auth/src/lib/auth.controller.ts` and change the controller:** + +```typescript +import { Body, Controller, Get, Post } from '@nestjs/common'; + +@Controller('auth') +export class AuthController { + @Get() + auth() { + return { + authenticated: true, + }; + } + + @Post() + authenticate(@Body() postData: { username: string; password: string }) { + const { username, password } = postData; + // check the database + console.log(username, password); + } +} +``` + +**Run `nx affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps are affected by this change. + +**Run `nx affected:libs`**, and you should see `auth` 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 `nx affected:test` to retest only the projects affected by the change.** + +As you can see, since we updated the code, without updating the tests, the unit tests failed. + +```bash +> NX Running target test for projects: + + - auth + - todos + +... + + Failed projects: + + - todos +``` + +Note that Nx only tried to retest `auth` and `todos`. It didn't retest `data` because there is no way that library could be affected by the changes in this branch. + +## Affected:\* + +You can run any target against the affected projects in the graph like this: + +```bash +# The following are equivalent +nx affected --target=build +nx affected:build +``` + +!!!!! +Run "nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects with "invalid" were run +An error message saying that the "invalid" target is invalid diff --git a/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/08-summary.md b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/08-summary.md new file mode 100644 index 0000000000..9af8abcb5c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/node/tutorial/08-summary.md @@ -0,0 +1,18 @@ +# Step 8: Summary + +In this tutorial you: + +- Built a full Node application with an API and server side rendered pages +- Shared code +- Created a Controller library +- Used Nx dep graph capabilities 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](/{{framework}}/cli/overview) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/ng-packagr-lite.md new file mode 100644 index 0000000000..667a7b33ab --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/ng-packagr-lite.md @@ -0,0 +1,36 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/package.md new file mode 100644 index 0000000000..3d66db0326 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/package.md @@ -0,0 +1,46 @@ +# package + +Build and package an Angular library for publishing + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/webpack-browser.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/webpack-browser.md new file mode 100644 index 0000000000..4efbc5a16e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/builders/webpack-browser.md @@ -0,0 +1,334 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +Type: `boolean` + +Log progress to the console while building. + +### rebaseRootRelativeCssUrls + +Default: `false` + +Type: `boolean` + +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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/10.4.13/react/api-angular/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/application.md new file mode 100644 index 0000000000..a895bddf45 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/10.4.13/react/api-angular/schematics/downgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/downgrade-module.md new file mode 100644 index 0000000000..83a9b97974 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup 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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma-project.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma-project.md new file mode 100644 index 0000000000..fb87bebaa3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing 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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma.md new file mode 100644 index 0000000000..fa41a5fe46 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/karma.md @@ -0,0 +1,23 @@ +# karma + +Add 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 +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/library.md new file mode 100644 index 0000000000..fb756b7a75 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/library.md @@ -0,0 +1,177 @@ +# library + +Create 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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### 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. 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: `tslint` + +Type: `string` + +Possible values: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/10.4.13/react/api-angular/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/move.md new file mode 100644 index 0000000000..835e09dc50 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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/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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/ngrx.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/ngrx.md new file mode 100644 index 0000000000..9d4a0f23dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## 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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/10.4.13/react/api-angular/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/stories.md new file mode 100644 index 0000000000..2c028bd632 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/stories.md @@ -0,0 +1,37 @@ +# 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/angular:stories ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g stories ... --dry-run +``` + +## Options + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/storybook-configuration.md new file mode 100644 index 0000000000..59170f1310 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a 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/angular:storybook-configuration ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g storybook-configuration ... --dry-run +``` + +## Options + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library + +### linter + +Default: `tslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/upgrade-module.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/upgrade-module.md new file mode 100644 index 0000000000..093f05de01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-angular/schematics/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add 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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/10.4.13/react/api-cypress/builders/cypress.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-cypress/builders/cypress.md new file mode 100644 index 0000000000..7442d5d345 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-cypress/builders/cypress.md @@ -0,0 +1,126 @@ +# cypress + +Run Cypress e2e tests + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/10.4.13/react/api-express/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-express/schematics/application.md new file mode 100644 index 0000000000..c801960e6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-express/schematics/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/react/api-jest/builders/jest.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-jest/builders/jest.md new file mode 100644 index 0000000000..db8bcb0e4e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-jest/builders/jest.md @@ -0,0 +1,222 @@ +# jest + +Run Jest unit tests + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/eslint.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/eslint.md new file mode 100644 index 0000000000..a2af8e391b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/eslint.md @@ -0,0 +1,94 @@ +# eslint + +Run ESLint on a project + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/lint.md new file mode 100644 index 0000000000..199f5123b0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-linter/builders/lint.md @@ -0,0 +1,110 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/10.4.13/react/api-nest/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/application.md new file mode 100644 index 0000000000..cca4d44354 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest 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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/react/api-nest/schematics/class.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/class.md new file mode 100644 index 0000000000..919d78f9cc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/class.md @@ -0,0 +1,65 @@ +# class + +Run the 'class' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/controller.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/controller.md new file mode 100644 index 0000000000..6d876ec3ee --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/controller.md @@ -0,0 +1,65 @@ +# controller + +Run the 'controller' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/decorator.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/decorator.md new file mode 100644 index 0000000000..30c763bfe1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/decorator.md @@ -0,0 +1,65 @@ +# decorator + +Run the 'decorator' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/filter.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/filter.md new file mode 100644 index 0000000000..574c0bb7fa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/filter.md @@ -0,0 +1,65 @@ +# filter + +Run the 'filter' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/gateway.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/gateway.md new file mode 100644 index 0000000000..0c84025bed --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/gateway.md @@ -0,0 +1,65 @@ +# gateway + +Run the 'gateway' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/guard.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/guard.md new file mode 100644 index 0000000000..07c00cac00 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/guard.md @@ -0,0 +1,65 @@ +# guard + +Run the 'guard' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interceptor.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interceptor.md new file mode 100644 index 0000000000..ba3aff009e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interceptor.md @@ -0,0 +1,65 @@ +# interceptor + +Run the 'interceptor' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interface.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interface.md new file mode 100644 index 0000000000..6392eb510c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/interface.md @@ -0,0 +1,65 @@ +# interface + +Run the 'interface' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/library.md new file mode 100644 index 0000000000..5a96b01c79 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/library.md @@ -0,0 +1,159 @@ +# library + +Create a new nest 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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/react/api-nest/schematics/middleware.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/middleware.md new file mode 100644 index 0000000000..8f4f48344e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/middleware.md @@ -0,0 +1,65 @@ +# middleware + +Run the 'middleware' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/module.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/module.md new file mode 100644 index 0000000000..9d36d9e18e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/module.md @@ -0,0 +1,65 @@ +# module + +Run the 'module' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/pipe.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/pipe.md new file mode 100644 index 0000000000..49992338e2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/pipe.md @@ -0,0 +1,65 @@ +# pipe + +Run the 'pipe' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/provider.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/provider.md new file mode 100644 index 0000000000..6ea1995f14 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/provider.md @@ -0,0 +1,65 @@ +# provider + +Run the 'provider' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/resolver.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/resolver.md new file mode 100644 index 0000000000..35a7bf480c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/resolver.md @@ -0,0 +1,65 @@ +# resolver + +Run the 'resolver' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/service.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/service.md new file mode 100644 index 0000000000..78da4067aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nest/schematics/service.md @@ -0,0 +1,65 @@ +# service + +Run the 'service' NestJs Schematic 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated schematic + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/build.md new file mode 100644 index 0000000000..f3b464f265 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/build.md @@ -0,0 +1,44 @@ +# build + +Build a Next.js app + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/export.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/export.md new file mode 100644 index 0000000000..e6885d3740 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/export.md @@ -0,0 +1,28 @@ +# export + +Export a Next.js app. The exported application is located at dist/\$outputPath/exported. + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### 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/data-access-documents/src/data/10.4.13/react/api-next/builders/server.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/server.md new file mode 100644 index 0000000000..095e48e2d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/builders/server.md @@ -0,0 +1,64 @@ +# server + +Serve a Next.js app + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/react/api-next/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/application.md new file mode 100644 index 0000000000..ec0c74b2b2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/application.md @@ -0,0 +1,123 @@ +# 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 + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style) + +### 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. + +### 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/data-access-documents/src/data/10.4.13/react/api-next/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/component.md new file mode 100644 index 0000000000..bb6cffb91e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/component.md @@ -0,0 +1,107 @@ +# 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/react/api-next/schematics/page.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/page.md new file mode 100644 index 0000000000..82ca21954e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-next/schematics/page.md @@ -0,0 +1,107 @@ +# 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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/react/api-node/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/build.md new file mode 100644 index 0000000000..0ca8edc43c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/build.md @@ -0,0 +1,162 @@ +# build + +Build a Node application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### buildLibsFromSource + +Default: `false` + +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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/execute.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/execute.md new file mode 100644 index 0000000000..142e72e3f7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/execute.md @@ -0,0 +1,64 @@ +# execute + +Execute a Node application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/10.4.13/react/api-node/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/package.md new file mode 100644 index 0000000000..bb47b3db6d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/builders/package.md @@ -0,0 +1,78 @@ +# package + +Package a Node library + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/react/api-node/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/schematics/application.md new file mode 100644 index 0000000000..5ed7f18cd4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/schematics/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/10.4.13/react/api-node/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/schematics/library.md new file mode 100644 index 0000000000..1320501c10 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-node/schematics/library.md @@ -0,0 +1,159 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/react/api-nx-plugin/builders/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/builders/e2e.md new file mode 100644 index 0000000000..326849b24b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/builders/e2e.md @@ -0,0 +1,26 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/builder.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/builder.md new file mode 100644 index 0000000000..63c86c4e42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/builder.md @@ -0,0 +1,65 @@ +# builder + +Create a builder for an Nx Plugin + +## Usage + +```bash +nx generate builder ... +``` + +By default, Nx will search for `builder` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:builder ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g builder ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/builders/my-builder: + +```bash +nx g builder my-builder --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Builder description + +### name + +Type: `string` + +Builder name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/migration.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/migration.md new file mode 100644 index 0000000000..d8ebce862a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/migration.md @@ -0,0 +1,83 @@ +# 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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/plugin.md new file mode 100644 index 0000000000..f7bce6c1ba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/plugin.md @@ -0,0 +1,97 @@ +# 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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/schematic.md new file mode 100644 index 0000000000..dd34d31cdc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-nx-plugin/schematics/schematic.md @@ -0,0 +1,65 @@ +# schematic + +Create a schematic for an Nx Plugin + +## Usage + +```bash +nx generate schematic ... +``` + +By default, Nx will search for `schematic` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/nx-plugin:schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g schematic ... --dry-run +``` + +### Examples + +Generate libs/my-plugin/src/schematics/my-schematic: + +```bash +nx g schematic my-schematic --project=my-plugin +``` + +## Options + +### description + +Alias(es): d + +Type: `string` + +Schematic description + +### name + +Type: `string` + +Schematic name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/application.md new file mode 100644 index 0000000000..305c382e5d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/application.md @@ -0,0 +1,165 @@ +# 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/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. + +### 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. + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipWorkspaceJson + +Default: `false` + +Type: `boolean` + +Skip updating workspace.json with default schematic options based on values provided to this app (e.g. babel, style). + +### 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/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-cypress-spec.md new file mode 100644 index 0000000000..58b52f635a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-story.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-story.md new file mode 100644 index 0000000000..35ef6ced9c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component-story.md @@ -0,0 +1,37 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component.md new file mode 100644 index 0000000000..8fe208e4ec --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/component.md @@ -0,0 +1,137 @@ +# component + +Create a 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/10.4.13/react/api-react/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/library.md new file mode 100644 index 0000000000..81cf8a607f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/library.md @@ -0,0 +1,173 @@ +# 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/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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### directory + +Alias(es): d + +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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/react/api-react/schematics/redux.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/redux.md new file mode 100644 index 0000000000..cda1e636d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/redux.md @@ -0,0 +1,67 @@ +# 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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/10.4.13/react/api-react/schematics/stories.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/stories.md new file mode 100644 index 0000000000..69ae7ee393 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/stories.md @@ -0,0 +1,45 @@ +# 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 + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic. + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/storybook-configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/storybook-configuration.md new file mode 100644 index 0000000000..d5a59afb47 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-react/schematics/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure schematic + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/build.md new file mode 100644 index 0000000000..05648b0378 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/build.md @@ -0,0 +1,38 @@ +# build + +Build Storybook + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/storybook.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/storybook.md new file mode 100644 index 0000000000..cbe82db023 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/builders/storybook.md @@ -0,0 +1,82 @@ +# storybook + +Serve Storybook + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### port + +Default: `9009` + +Type: `number` + +Port to listen on. + +### quiet + +Default: `true` + +Type: `boolean` + +Suppress verbose build output. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/configuration.md new file mode 100644 index 0000000000..65eb7bc7c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/configuration.md @@ -0,0 +1,63 @@ +# configuration + +Add storybook configuration to a ui library + +## 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure schematic + +### 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` + +Library name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/cypress-project.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/cypress-project.md new file mode 100644 index 0000000000..ed108f43ac --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-storybook/schematics/cypress-project.md @@ -0,0 +1,49 @@ +# 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 + +### 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` + +Library name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/build.md new file mode 100644 index 0000000000..787193fec8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/build.md @@ -0,0 +1,244 @@ +# build + +Build a application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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: `false` + +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. + +### crossOrigin + +Type: `string` + +The crossorigin attribute to use for generated javascript script tags. One of 'none' | 'anonymous' | 'use-credentials' + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/10.4.13/react/api-web/builders/dev-server.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/dev-server.md new file mode 100644 index 0000000000..e9479059e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/dev-server.md @@ -0,0 +1,106 @@ +# dev-server + +Serve a web application + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/10.4.13/react/api-web/builders/package.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/package.md new file mode 100644 index 0000000000..726ee5cf4f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/builders/package.md @@ -0,0 +1,114 @@ +# package + +Package a library + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/10.4.13/react/api-web/schematics/application.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/schematics/application.md new file mode 100644 index 0000000000..914d89a1c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-web/schematics/application.md @@ -0,0 +1,103 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/10.4.13/react/api-workspace/builders/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/builders/run-commands.md new file mode 100644 index 0000000000..b8bed6f2f8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/builders/run-commands.md @@ -0,0 +1,220 @@ +# run-commands + +Run any custom commands with Nx + +Builder properties can be configured in workspace.json when defining the builder, or when invoking it. +Read more about how to use builders and the CLI here: https://nx.dev/react/guides/cli. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/library.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/library.md new file mode 100644 index 0000000000..681c06659f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/library.md @@ -0,0 +1,133 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/move.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/move.md new file mode 100644 index 0000000000..8f7f38a34e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/move.md @@ -0,0 +1,65 @@ +# 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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the schematic update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/remove.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/remove.md new file mode 100644 index 0000000000..a83d277938 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/remove.md @@ -0,0 +1,71 @@ +# 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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/run-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/run-commands.md new file mode 100644 index 0000000000..6ab77cfeba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/run-commands.md @@ -0,0 +1,67 @@ +# 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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/workspace-schematic.md new file mode 100644 index 0000000000..d90b6755c4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/api-workspace/schematics/workspace-schematic.md @@ -0,0 +1,39 @@ +# workspace-schematic + +Generates a workspace schematic + +## Usage + +```bash +nx generate workspace-schematic ... +``` + +By default, Nx will search for `workspace-schematic` in the default collection provisioned in `workspace.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/workspace:workspace-schematic ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g workspace-schematic ... --dry-run +``` + +## Options + +### name + +Type: `string` + +Schematic name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/builders.json b/nx-dev/data-access-documents/src/data/10.4.13/react/builders.json new file mode 100644 index 0000000000..722846ec08 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/builders.json @@ -0,0 +1,14 @@ +[ + "angular", + "cypress", + "express", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/react/cli/affected-build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-build.md new file mode 100644 index 0000000000..76dc8d0795 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-build.md @@ -0,0 +1,137 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/react/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-e2e.md new file mode 100644 index 0000000000..f6a9518562 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-e2e.md @@ -0,0 +1,125 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/react/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/10.4.13/react/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-lint.md new file mode 100644 index 0000000000..ebf0491368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-lint.md @@ -0,0 +1,125 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/react/cli/affected-test.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-test.md new file mode 100644 index 0000000000..663ec95368 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected-test.md @@ -0,0 +1,125 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/react/cli/affected.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected.md new file mode 100644 index 0000000000..874b43a5c6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/affected.md @@ -0,0 +1,147 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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/data-access-documents/src/data/10.4.13/react/cli/build.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/10.4.13/react/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/e2e.md new file mode 100644 index 0000000000..1fdb16dc1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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 & autmatically 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/data-access-documents/src/data/10.4.13/react/cli/format-check.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/react/cli/format-write.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/10.4.13/react/cli/generate.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/generate.md new file mode 100644 index 0000000000..033fcfd871 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/generate.md @@ -0,0 +1,93 @@ +# generate + +Runs a schematic that generates and/or modifies files based on a schematic from a collection. + +## Usage + +```bash +nx generate +``` + +```bash +nx g +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 schematics in the default collection. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/10.4.13/react/cli/list.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/list.md new file mode 100644 index 0000000000..09742dbc9b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +List the plugins installed in the current workspace: + +```bash +nx list +``` + +List the schematics and builders 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/migrate.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/react/cli/print-affected.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/10.4.13/react/cli/report.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run-many.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run-many.md new file mode 100644 index 0000000000..11f3319105 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run-many.md @@ -0,0 +1,101 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Default: `3` + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Default: `false` + +Parallelize the command + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/react/cli/serve.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/10.4.13/react/cli/test.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/10.4.13/react/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/cli/workspace-schematic.md b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/workspace-schematic.md new file mode 100644 index 0000000000..1935090762 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/cli/workspace-schematic.md @@ -0,0 +1,29 @@ +# workspace-schematic + +Runs a workspace schematic from the tools/schematics directory + +## Usage + +```bash +nx workspace-schematic +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### list-schematics + +List the available workspace-schematics + +### name + +The name of your schematic` + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/examples/apollo-react.md b/nx-dev/data-access-documents/src/data/10.4.13/react/examples/apollo-react.md new file mode 100644 index 0000000000..e3aa0cbe28 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/examples/apollo-react.md @@ -0,0 +1,12 @@ +# 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/data-access-documents/src/data/10.4.13/react/examples/react-nx.md b/nx-dev/data-access-documents/src/data/10.4.13/react/examples/react-nx.md new file mode 100644 index 0000000000..3f638680f1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/examples/react-nx.md @@ -0,0 +1,12 @@ +# 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. +- Generate React components with a schematic +- 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/data-access-documents/src/data/10.4.13/react/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/resources.md b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/resources.md new file mode 100644 index 0000000000..aff14c088b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/resources.md @@ -0,0 +1,118 @@ +# Resources + +## 45-Minute Walkthrough + + + +## Quick Introductions (10 minutes) + + + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## Resources + +### Talks + +- [React Development At Scale (React Vancouver Virtual Meetup)](https://youtu.be/ZGXuzVipe1U?t=3721), Jack Hsu (May 27, 2020) + +- [Scalable React Development (React Summit Remote Edition)](https://www.youtube.com/watch?v=Lr-u2ALSEQg), Jason Jean (April 17, 2020) + Slides: [https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/](https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/) + +- [Beyond Basics: Scaling Development across Large Teams (Angular Rome Meetup online)](https://docs.google.com/presentation/d/1zEgeppole9avhrvV6Zmpmk-L1W9-6JsHbnjaJwBigtQ/edit?usp=sharing), Juri Strumpflohner (April 2, 2020) + +- [Develop like Google, Microsoft, and Facebook with Nx - Dev Nexus](https://prezi.com/view/BVhl92reqg7cnhvv6hhH/), Jason Jean (February 18, 2020) + +- [Enhancing the workspace with Custom Builders - AngularToronto](https://www.youtube.com/watch?v=M1Bk_O49n94), Benjamin Cabanes (February 18, 2020) + +- [Advanced Nx - Angular Air](https://www.youtube.com/watch?v=pcTSDMid-aE), Isaac Mann (February 5th, 2020) + +- [Teach Me Anything - HackFlix](https://www.youtube.com/watch?v=WRmj4JwfoMs) - Isaac Mann (January 9th, 2020) + +* [E2E Testing at Half the Cost - NG-BE 2019](https://www.youtube.com/watch?v=C88th0SbepE), Isaac Mann (Dev 10, 2019) + +* [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +* [Building Large Angular Apps - ngBucharest](https://www.youtube.com/watch?v=bKhyTeTCf7M), Isaac Mann (March 30, 2019) + + - Slides: [https://prezi.com/view/jglXvEfeqnjEr4l2L11h/](https://prezi.com/view/jglXvEfeqnjEr4l2L11h/) + +* [Modern Development with Angular CLI & Nrwl Nx](https://www.youtube.com/watch?v=tE8sUAfKI3g), Victor Savkin at ngAtlanta (Feb 5, 2019) + +* [Supercharging the Angular CLI](https://www.youtube.com/watch?v=bMkKz8AedHc) - ngVikings, James Henry (March 10, 2018) + +* [Hands on Full Stack development with Nx and Bazel](https://www.youtube.com/watch?v=1KDDIhcQORM) - ngConf, Alex Eagle, Torgeir Helgevold (April 19, 2018) + +* [Angular at Large Organizations](https://www.youtube.com/watch?v=piQ0EZhtus0) - ngConf, Victor Savkin(April 20, 2018) + +* [Building Large Angular Apps Successfully with Nx - AngularNYC Meetup](https://youtu.be/Jwv3wRZ3BTM), Jason Jean (December 19, 2018) + +- [Nx: The New Way to Build Enterprise Angular Apps](https://www.youtube.com/watch?v=xo-1SDmvM8Y) - Angular Mix, Jeff Cross & Victor Savkin (October 11, 2017) + +### Podcasts and Shows + +- [Nx Plugins - ngHouston](https://youtu.be/bydqr-Yxsu8), Wes Grimes and Jon Cammisuli (April 8 2020) + +- [Apollo GQL, Angular & Nx - ngHouston](https://youtu.be/bydqr-Yxsu8), Philip Fulcher (Feb 26, 2020) + +- [Teach Me Anything - With Isaac Mann from Nrwl](https://youtu.be/WRmj4JwfoMs), Isaac Mann (Jan 9, 2020) + +- [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +- [React Roundup: Nx and Monorepos](https://player.fm/series/react-round-up/rru-081-nx-and-monorepos-with-jeffrey-cross-and-victor-savkin), Victor Savkin (Oct 1, 2019) + +- [Nx and Angular CLI - Adventures in Angular](https://devchat.tv/adv-in-angular/aia-254-nx-and-angular-cli-with-brandon-roberts/), Brandon Roberts (Aug 27th 2019) + +- [ngHouston: NX Demo](https://www.youtube.com/watch?v=E_UlU2Yv4G0) (Dec 7, 2017) + +- [ngAir 140: Nx for Enterprise Angular Development](https://www.youtube.com/watch?v=qYNiOKDno_I), Victor Savkin (Dec 12, 2017) + +### Nx Demo & Tutorial Videos + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (Angular)](https://youtu.be/h5FIGDn5YM0) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Nx Console - A Must-Have Visual Studio Code Extension for Angular Developers](https://youtu.be/IIetmfgozgI) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +### Books amd Blogs + +- [Nx blog posts](https://blog.nrwl.io/nx/home) + +- [Angular Enterprise Monorepo Patterns Book (free)](https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book?utm_campaign=Book%3A%20Monorepo%20Patterns%2C%20Jan%202019&utm_source=Github&utm_medium=Banner%20Ad) + +* [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +* [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +- [Tiny Angular application projects in Nx workspaces](https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/#peer-reviewers--30/) (March 2020) + +### Misc + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [xplat - Cross-platform tools for Nx workspaces](https://nstudio.io/xplat/) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/why-nx.md b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/why-nx.md new file mode 100644 index 0000000000..55fc46217e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/getting-started/why-nx.md @@ -0,0 +1,61 @@ +# Why Nx? + +Nx is the preeminent toolkit for Monorepo development, which helps you to build software smarter and faster. With Nx you can build full-stack applications with your preferred framework, integrate with modern tools you’re probably already using, and reinforce best practices for your entire development team or enterprise. Use Nx to build software at scale, the better way. + +- Out of the box integration with Cypress, Jest, Typescript, Prettier + more +- Has a growing ecosystem, and a community plugin market +- Many leading enterprises are already using Nx to build the software you know and love + +## 10-Minute Nx Overview + + + +## Why Monorepos? + +A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them. + +### What are the benefits of a monorepo? + +- **Shared code** - Keep your code DRY across your entire organization. Reuse validation code, UI components and types across the code base. Reuse code between the backend and the frontend. +- **Atomic changes** - Change a server API and modify the clients that consume that API in the same commit. You can change a button component in a shared library and the applications that use that component in the same commit. This saves the pain of trying to coordinate commits across multiple repositories. +- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe. +- **Single set of dependencies** - Use a single version of third party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3 year old version of a framework library or an old version of webpack. + +## Why Not Code Collocation? + +A naive implementation of a monorepo is simply code collocation - placing all the code from multiple repositories into the same repo without adequate tooling to coordinate everything. What problems arise from code collocation? + +- **Running unnecessary tests** - In order to ensure nothing was broken by a change, all tests in the entire repository need to be run - even code in projects that are unrelated to the actual change. +- **No code boundaries** - A developer from another team can change code in your project, causing bugs or inconsistencies. Or worse, another team can use code that you intended for private use - forcing you to never change that code for fear of breaking their application. +- **Inconsistent tooling** - Each project uses its own set of commands for running tests, building, serving, etc. This makes it very difficult to move from project to project. + +Tools like Lerna and Yarn Workspaces help optimize the installation of node modules, but they **do not** enable Monorepo-style development. In other words, they solve an orthogonal problem and sometimes can be used in combination with Nx. Read more on it [here](https://blog.nrwl.io/why-you-should-switch-from-lerna-to-nx-463bcaf6821). + +## Nx Can Help + +Nx provides tools to give you the benefits of a monorepo without the drawbacks of simple code collocation. + +### Scaling Your Repo + +- **Faster Command Execution** - Builders allow for consistent commands to test, serve, build, lint, etc, each project. [Nx’s affected command]() helps run commands only on code that is affected by the current change. Nx provides local and distributed caching of builder commands so when someone on your team runs a command, everyone else will use their artifacts to speed up their own command executions, often bringing them down from minutes to seconds. This, in combination with support for distributed and incremental builds helps you scale your development to massive applications and repositories. + +### Scaling Your Organization + +- **Controlled Code Sharing** - You can define libraries with specific enforced APIs and put rules in place to define how those libraries can depend on each other. A CODEOWNERS file can be used to restrict who is allowed to change files in each project. +- **Consistent Code Generation** - Schematics allow you to automate code creation and modification tasks. Instead of writing a 7 step guide in a readme file, you can create a schematic to prompt the developer for inputs and then modify the code directly. Nrwl provides plugins which contain useful builders and schematics for a lot of popular tools. Also, there is a growing number of community provided plugins. +- **Accurate Architecture Diagram** - Most architecture diagrams are wrong the moment they are written down. And every diagram becomes out of date as soon as the code changes. Since Nx understands your code, it can generate an up-to-date and accurate diagram of how projects depend on each other. And for cases where dependencies are not explicit in the code, you can manually tell Nx about project dependencies. + +## Next Steps + +**Learn Nx Fundamentals:** + +- [Interactive Nx Tutorial](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) +- [45-Minute Walkthrough](https://www.youtube.com/watch?v=jCf92IyR-GE) + +**Dive Deep:** + +- [Nx CLI](/{{framework}}/cli/overview) +- [Configuration Files](/{{framework}}/workspace/configuration) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/adding-assets.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/adding-assets.md new file mode 100644 index 0000000000..a4e9ffb837 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/adding-assets.md @@ -0,0 +1,39 @@ +# Adding Images, Fonts, and Files + +With Nx, you can **`import` assets directly from your TypeScript/JavaScript code**. + +```typescript jsx +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 jsx +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. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/cli-overview.md new file mode 100644 index 0000000000..82a94514c7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/cli-overview.md @@ -0,0 +1,267 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/react`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called schematics. Schematics provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/react:application myapp +``` + +The `@nrwl/react` package contains a collection of schematics, with `application` being the one used in this example. The Nx CLI applies the schematic to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the schematic. + +```sh +nx generate @nrwl/react:application myapp --style=scss +``` + +You can preview the changes a schematic makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the schematic. + +**Generate command:** + +`nx generate` runs schematics to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[schematic-name] [options]` + Example: `nx generate @nrwl/react:component mycmp --project=myapp` + +## Running Tasks + +The Nx CLI uses builders to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +A builder is a function that uses the Architect API to perform a complex process such as "build", "test", or "lint". + +You can configure the builders in `workspace.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "architect": { + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` builder, and the `test` target uses `@nrwl/jest:jest`. Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # producttion configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any builders you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx affected --target=build --prod +``` + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/configuration.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/configuration.md new file mode 100644 index 0000000000..35c9ee8d02 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/configuration.md @@ -0,0 +1,358 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## workspace.json + +The `workspace.json` configuration file contains information about the targets and schematics. Let's look at the following example: + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "myapp:build", + "proxyConfig": "apps/myapp/proxy.conf.json" + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js", + "tsConfig": "apps/myapp/tsconfig.spec.json" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": { + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/react" + }, + "schematics": { + "@nrwl/react:library": { + "js": true + } + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": {} + } +} +``` + +- `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'. +- `architect` configures all the targets which define what tasks you can run against the library. + +> Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular. + +### Targets + +Let's look at the simple architect target: + +```json +{ + "test": { + "builder": "@nrwl/jest:jest", + "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 run mylib:mytest`. + +**Builder** + +The `builder` 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 builder named `jest` and invoke it with the options. + +**Options** + +The `options` provides a map of values that will be passed to the builder. 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 builder: + +```json +{ + "jestConfig": "libs/mylib/another-jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" +} +``` + +**Outputs** + +The `outputs` property lists the folders the builder will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + } +} +``` + +You can select a configuration like this: `nx build myapp --configuration=production` or `nx run myapp:build:configuration=production`. + +The following show how the builder options get constructed: + +```bash +require(`@nrwl/jest`).builders['jest']({...options, ...selectedConfiguration, ...commandLineArgs}}) // Pseudocode +``` + +The selected configuration adds/overrides the default options, and the provided command line args add/override the configuration options. + +### Schematics + +You can configure default schematic options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. + +```json +{ + "schematics": { + "@nrwl/react:library": { + "js": true + } + } +} +``` + +You can also do it on the project level: + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "schematics": { + "@nrwl/react:component": { + "classComponent": true + } + }, + "architect": {} + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/react:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/react" + } +} +``` + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "workspace.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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 dependencies between shared files and projects 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` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/environment-variables.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/environment-variables.md new file mode 100644 index 0000000000..aa9997a750 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/environment-variables.md @@ -0,0 +1,66 @@ +# 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 and NX prefixed env vars such as: `NODE_ENV` or `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` +3. `workspaceRoot/.local.env` +4. `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 `.local.env` files for their local environment and override any project defaults set in `.env` + +For example: + +1. `workspaceRoot/apps/my-app/.local.env` 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/.local.env` 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](https://nx.dev/react/workspace/computation-caching#nx-cloud-and-distributed-computation-memoization)). + +### 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](https://nx.dev/react/plugins/workspace/builders/run-commands#envfile) builder and execute your command inside of the builder diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/js-and-ts.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/js-and-ts.md new file mode 100644 index 0000000000..f0c6f9e601 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/js-and-ts.md @@ -0,0 +1,14 @@ +# 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.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/data-access-documents/src/data/10.4.13/react/guides/nextjs.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/nextjs.md new file mode 100644 index 0000000000..9ee11a36be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/nextjs.md @@ -0,0 +1,144 @@ +# Next.js + +Nx comes with first-class Next.js support. In this guide we will look at how to use it. + +## Creating a New Nx Workspace + +Create a new Nx workspace. The easiest way to do it is to use npx. + +```bash +npx --ignore-existing create-nx-workspace happynrwl +``` + +You can also create a workspace with a Next.js application in place by running: + +```bash +npx --ignore-existing create-nx-workspace happynrwl --preset=next +``` + +## Adding Next.js capabilities to a workspace + +If you used the Next.js preset, you are all set and can skip this. If you created an empty workspace or have an existing workspace, you can add Next.js capabilities to the workspace: + +```bash +yarn add --dev @nrwl/next +``` + +## Generating a Next.js Application + +Run + +```bash +nx g @nrwl/next:app tuskdesk +``` + +and you will see the following: + +```treeview +happynrwl/ +├── apps/ +│   ├── tuskdesk/ +│   │   ├── pages/ +│   │   │   ├── index.css +│   │   │   └── index.tsx +│   │   ├── jest.conf.js +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── .eslintrc.json +│   └── tuskdesk-e2e/ +│   │   ├── src/ +│   │   │   ├── integrations/ +│   │   │   │   └── app.spec.ts +│   │   │   ├── fixtures/ +│   │   │   ├── plugins/ +│   │   │   └── support/ +│   │   ├── cypress.json +│   │   ├── tsconfig.e2e.json +│   │   └── .eslintrc.json +├── libs/ +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── .eslintrc.json +``` + +Run: + +- `nx serve tuskdesk` to serve the application +- `nx serve tuskdesk --prod` to serve the application in the production mode +- `nx build tuskdesk` to build the application +- `nx lint tuskdesk` to lint the application +- `nx test tuskdesk` to test the application using Jest +- `nx export tuskdesk` to export the application +- `nx e2e tuskdesk-e2e` to test the application using Cypress + +When using Next.js in Nx, you get the out-of-the-box support for TypeScript, Cypress, Jest. No need to configure anything: watch mode, source maps, and typings just work. + +## Generating a React Library + +Run + +```bash +nx g @nrwl/react:lib shared-components +``` + +and you will see the following: + +```treeview +happynrwl/ +├── apps/ +│   ├── tuskdesk/ +│   └── tuskdesk-e2e/ +├── libs/ +│   └── shared-components/ +│   ├── src/ +│   │ ├── lib/ +│   │ │ ├── home.css +│   │ │ ├── home.tsx +│   │ │ └── home.spec.tsx +│   │ └ index.ts +│   ├── jest.config.js +│   ├── tsconfig.json +│   ├── tsconfig.lib.json +│   ├── tsconfig.spec.json +│   └── tslint.json +├── nx.json +├── workspace.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Run: + +- `nx test shared-components` to test the library +- `nx lint shared-components` to lint the library + +## Using the Library in an Application + +You can import the shared-components library into the Next.js application like this. + +```typescript jsx +import { Home } from '@happynrwl/shared-components'; +import React from 'react'; + +export const Index = () => { + return ( + <> + +
the rest of the component
+ + ); +}; + +export default Index; +``` + +## Sharing Code + +Without Nx, creating a new shared library can take from several hours or 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 components between multiple Next.js applications. You can also share web components between Next.js and plain React applications. You can even share code between the backend and the frontend. All can be done without any unnecessary ceremony. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/guides/storybook-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/storybook-plugin.md new file mode 100644 index 0000000000..acb33081d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/guides/storybook-plugin.md @@ -0,0 +1,322 @@ +# Storybook + +![Storybook logo](/shared/storybook-logo.png) + +Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. + +## How to Use Storybook in an Nx Repo + +### Add the Storybook plugin + +```bash +yarn add --dev @nrwl/storybook +``` + +### Generating Storybook Configuration + +You can generate Storybook configuration for an individual project with this command: + +```bash +nx g @nrwl/react:storybook-configuration project-name +``` + +If there's no `.storybook` folder at the root of the workspace, one is created. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── apps/ +├── libs/ +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +Also, a project-specific `.storybook` folder is added in the root of the project. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── config.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── src/ +├── README.md +├── tsconfig.json +└── etc... +``` + +### Running Storybook + +Serve Storybook using this command: + +```bash +nx run project-name:storybook +``` + +### Run Cypress Tests Against a Storybook Instance + +Both `storybook-configuration` schematic gives the option to set up an e2e Cypress app that is configured to run against the project's Storybook instance. + +To launch Storybook and run the Cypress tests against the iframe inside of Storybook: + +```bash +nx run project-name-e2e:e2e +``` + +The url that Cypress points to should look like this: + +`'/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default'` + +- `buttoncomponent` is a lowercase version of the `Title` in the `*.stories.ts` file. +- `primary` is the name of an individual story. +- `knob-style=default` sets the `style` knob to a value of `default`. + +Changing knobs in the url query parameters allows your Cypress tests to test different configurations of your component. + +### Example Files + +**\*.stories.tsx file** + +```ts +import React from 'react'; +import { text, number } from '@storybook/addon-knobs'; +import { Button } from './button'; + +export default { title: 'Button' }; + +export const primary = () => ( + + + ); +}; + +export default App; +``` + +The tests should pass now. + +!!!!! +What will you see if you run: `npx nx e2e todos-e2e --headless` +!!!!! +Cypress will run in the headless mode, and the test will pass. +Cypress will run in the headless mode, and the test will fail. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/04-connect-to-api.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/04-connect-to-api.md new file mode 100644 index 0000000000..28dc8bfae5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/04-connect-to-api.md @@ -0,0 +1,61 @@ +# Step 4: Connect to an API + +## Video of this Lesson + + + +Real-world applications do not live in isolation — they need APIs to talk to. Setup your app to talk to an API. + +**Let's change our application to fetch the data from the API.** + +```typescript jsx +import React, { useEffect, useState } from 'react'; + +interface Todo { + title: string; +} + +const App = () => { + const [todos, setTodos] = useState([]); + + useEffect(() => { + fetch('/api/todos') + .then((_) => _.json()) + .then(setTodos); + }, []); + + function addTodo() { + fetch('/api/addTodo', { + method: 'POST', + body: '', + }) + .then((_) => _.json()) + .then((newTodo) => { + setTodos([...todos, newTodo]); + }); + } + + return ( + <> +

Todos

+
    + {todos.map((t) => ( +
  • {t.title}
    • + ))} +
+ + + ); +}; + +export default App; +``` + +!!!!! +Run `npx nx serve todos` and open http://localhost:4200. What do you see? +!!!!! +"the server responded with a status of 404 (Not Found)" in Console. +Blank screen. +Exception rendered on the screen. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/05-add-node-app.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/05-add-node-app.md new file mode 100644 index 0000000000..cb6f78073f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/05-add-node-app.md @@ -0,0 +1,158 @@ +# Step 5: Add Node Application Implementing API + +## Video of this Lesson + + + +The requests fail because the API has not been created yet. Using Nx you can develop node applications next to your React 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 Express Plugin to Your Workspace + +Nx is an open platform with plugins for many modern tools and frameworks. **To see some plugins, run `npx nx list`:** + +```bash +> NX Installed plugins: + + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/linter (builders) + @nrwl/react (schematics) + @nrwl/web (builders,schematics) + @nrwl/workspace (builders,schematics) + + +> NX Also available: + + @nrwl/angular (schematics) + @nrwl/express (builders,schematics) + @nrwl/nest (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-plugin (builders,schematics) + @nrwl/storybook (builders,schematics) + + +> NX Community plugins: + + @nxtend/ionic-react - An Nx plugin for developing Ionic React applications and libraries + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + ... +``` + +**Now run `npx nx list @nrwl/express`, and you will see:** + +```bash +> NX NOTE @nrwl/express is not currently installed + + Use "yarn add --dev @nrwl/express" to add new capabilities +``` + +**Add the dependency:** + +```bash +npm install --save-dev @nrwl/express +``` + +or + +```bash +yarn add --dev @nrwl/express +``` + +> `@nrwl/express` also added `@nrwl/node`. Run `npx nx list @nrwl/express` and `npx nx list @nrwl/node` to see what those plugins provide. + +## Generate an Express Application + +**Run the following to generate a new Express application:** + +```bash +npx nx g @nrwl/express:app api --frontendProject=todos +``` + +After this is done, you should see something like this: + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +│      ├── src/ +│      │   ├── app/ +│      │   ├── 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/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.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 + +**Add a file `apps/api/src/app/todos.ts`.** + +```typescript +import { Express } from 'express'; + +interface Todo { + title: string; +} + +const todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; + +export function addTodoRoutes(app: Express) { + app.get('/api/todos', (req, resp) => resp.send(todos)); + app.post('/api/addTodo', (req, resp) => { + const newTodo = { + title: `New todo ${Math.floor(Math.random() * 1000)}`, + }; + todos.push(newTodo); + resp.send(newTodo); + }); +} +``` + +Here, you are building an Express application with Nx. Nx also comes with Nest support, and you can also use any other node library you want. + +**Next update `apps/api/src/main.ts` to register the routes** + +```typescript +import * as express from 'express'; +import { addTodoRoutes } from './app/todos'; + +const app = express(); + +app.get('/api', (req, res) => { + res.send({ message: 'Welcome to api!' }); +}); +addTodoRoutes(app); + +const port = process.env.port || 3333; +const server = app.listen(port, () => { + console.log(`Listening at http://localhost:${port}/api`); +}); +server.on('error', console.error); +``` + +!!!!! +Run "npx nx serve api" and open http://localhost:3333/api/todos. What do you see? +!!!!! +`[{"title":"Todo 1"},{"title":"Todo 2"}]` +Blank screen +404 diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/06-proxy.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/06-proxy.md new file mode 100644 index 0000000000..bb7d649bc1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/06-proxy.md @@ -0,0 +1,84 @@ +# Step 6: Proxy + +## Video of this Lesson + + + +You passed `--frontendProject=todos` when creating the node application. What did that argument do? + +It created a proxy configuration that allows the React application to talk to the API in development. + +**To see how it works, open `workspace.json` and find the `serve` target of the todos app.** + +```json +{ + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + } +} +``` + +**Note the `proxyConfig` property.** + +**Now open `proxy.conf.json`:** + +```json +{ + "/api": { + "target": "http://localhost:3333", + "secure": false + } +} +``` + +This configuration tells `npx nx serve` to forward all requests starting with `/api` to the process listening on port 3333. + +## Workspace.json, Targets, Builders + +You configure your workspaces in `workspace.json`. This file contains the workspace projects with their architect targets. For instance, `todos` has the `build`, `serve`, `lint`, and `test` targets. This means that you can run `npx nx build todos`, `npx nx serve todos`, etc.. + +Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +**Why not use shell scripts and npm scripts directly?** + +There are a lot of advantages to providing additional metadata to the build tool. For instance, you can introspect targets. `npx nx serve todos --help` results in: + +```bash +npx nx run todos:serve [options,...] + +Options: + --buildTarget Target which builds the application` + --port Port to listen on. (default: 4200) + --host Host to listen on. (default: localhost) + --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) + --liveReload Whether to reload the page on change, using live-reload. (default: true) + --publicHost Public URL where the application will be served + --open Open the application in the browser. + --allowedHosts This option allows you to whitelist services that are allowed to access the dev server. + --memoryLimit Memory limit for type checking service process in MB. + --maxWorkers Number of workers to use for type checking. + --help Show available options for project target. +``` + +It helps with good editor integration (see [VSCode Support](https://nx.dev/react/cli/console)). + +But, most importantly, it provides a holistic dev experience regardless of the tools used, and enables advanced build features like distributed computation caching and distributed builds). + +!!!!! +Now run both "npx nx serve todos" and "npx nx serve api" in separate terminals, open http://localhost:4200. What do you see? +!!!!! +Todos application is working! +404 in the console +Todos are displayed but the Add Todo button doesn't work diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/07-share-code.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/07-share-code.md new file mode 100644 index 0000000000..8edece892a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/07-share-code.md @@ -0,0 +1,95 @@ +# Step 7: Share Code + +## Video of this Lesson + + + +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 generator 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.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.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 recognised. This may need to be done **every time a new workspace library is added**. + +## Refactor the API + +**Now update `apps/api/src/app/todos.ts` to import the interface:** + +```typescript +import { Express } from 'express'; +import { Todo } from '@myorg/data'; + +const todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; + +export function addTodoRoutes(app: Express) { + app.get('/api/todos', (req, resp) => resp.send(todos)); + app.post('/api/addTodo', (req, resp) => { + const newTodo = { + title: `New todo ${Math.floor(Math.random() * 1000)}`, + }; + todos.push(newTodo); + resp.send(newTodo); + }); +} +``` + +## Update the React Application + +**Next import the interface in `apps/todos/src/app/app.tsx`:** + +```typescript jsx +import React, { useEffect, useState } from 'react'; +import { Todo } from '@myorg/data'; + +export const App = () => { + ... +}; + +export default App; +``` + +Every time you add a new library, you have to restart `npx nx serve`. **So restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between frontend and backend apps +Between different frontend apps +Between different node apps diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/08-create-libs.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/08-create-libs.md new file mode 100644 index 0000000000..48e1c79bbc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/08-create-libs.md @@ -0,0 +1,182 @@ +# Step 8: Create Libs + +## Video of this Lesson + + + +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 React components. + +Run + +```bash +npx nx g @nrwl/react:lib ui +``` + +You should see the following: + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +├── libs/ +│   ├── data/ +│ └── ui/ +│      ├── src/ +│      │   ├── lib/ +│      │   │ └── ui/ +│      │   │ ├── ui.css +│      │   │ ├── ui.spec.tsx +│      │   │ └── ui.tsx +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.json +``` + +The `libs/ui/src/lib/ui.tsx` file looks like this: + +```typescript jsx +import React from 'react'; + +import './ui.css'; + +export interface UiProps {} + +export const Ui = (props: UiProps) => { + return ( +
+

Welcome to ui!

+
+ ); +}; + +export default Ui; +``` + +## Add a Component + +Here, you can either change the UI component or generate a new one. + +**Add a component to the newly created ui library by running:** + +```bash +npx nx g @nrwl/react:component todos --project=ui --export +``` + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +├── libs/ +│   ├── data/ +│ └── ui/ +│      ├── src/ +│      │   ├── lib/ +│      │   │ ├── ui/ +│      │   │ │ ├── ui.css +│      │   │ │ ├── ui.spec.tsx +│      │   │ │ └── ui.tsx +│      │   │ └── todos/ +│      │   │ ├── todos.css +│      │   │ ├── todos.spec.tsx +│      │   │ └── todos.tsx +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +**Implement the Todos component.** + +```typescript jsx +import React from 'react'; +import { Todo } from '@myorg/data'; + +export const Todos = (props: { todos: Todo[] }) => { + return ( +
    + {props.todos.map((t) => ( +
  • {t.title}
    • + ))} +
+ ); +}; + +export default Todos; +``` + +## Use the UI Library + +**Now import `Todos` into `apps/todos/src/app/app.tsx`.** + +```typescript +import React, { useEffect, useState } from 'react'; +import { Todo } from '@myorg/data'; +import { Todos } from '@myorg/ui'; + +const App = () => { + const [todos, setTodos] = useState([]); + + useEffect(() => { + fetch('/api/todos') + .then((_) => _.json()) + .then(setTodos); + }, []); + + function addTodo() { + fetch('/api/addTodo', { + method: 'POST', + body: '', + }) + .then((_) => _.json()) + .then((newTodo) => { + setTodos([...todos, newTodo]); + }); + } + + return ( + <> +

Todos

+ + + + ); +}; + +export default App; +``` + +**Restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +> Nx helps you explore code generation options. Run `npx nx g @nrwl/react:component --help` to see all options available. Pass `--dry-run` to the command to see what would be generated without actually changing anything, like this: `npx nx g @nrwl/react:component mycmp --project=ui --dry-run`. + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +workspace.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/09-dep-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/09-dep-graph.md new file mode 100644 index 0000000000..3fb1e88128 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/09-dep-graph.md @@ -0,0 +1,18 @@ +# Step 9: Dep Graph + +## Video of this Lesson + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "npx nx dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/10-computation-caching.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/10-computation-caching.md new file mode 100644 index 0000000000..3bb4d23342 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/10-computation-caching.md @@ -0,0 +1,103 @@ +# Step 10: Computation Caching + +## Video of this Lesson + + + +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 +> npx nx run todos:build + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: c38fbdb8b372af447180 +Built at: 03/26/2020 11:03:57 AM +Entrypoint main = runtime.ff0534391bf88384547e.js main.b8dbcd3d3fd2900377f2.esm.js +Entrypoint polyfills = runtime.ff0534391bf88384547e.js polyfills.55535a35b1529d884ca3.esm.js +Entrypoint styles = runtime.ff0534391bf88384547e.js styles.3ff695c00d717f2d2a11.css +chunk {0} runtime.ff0534391bf88384547e.js (runtime) 0 bytes ={1}= ={2}= ={3}= [entry] [rendered] +chunk {1} main.b8dbcd3d3fd2900377f2.esm.js (main) 155 KiB ={0}= [initial] [rendered] +chunk {2} polyfills.55535a35b1529d884ca3.esm.js (polyfills) 239 KiB ={0}= [initial] [rendered] +chunk {3} styles.3ff695c00d717f2d2a11.css (styles) 147 bytes ={0}= [initial] [rendered] +``` + +**Now, run `npx nx build todos` again, and you will see the results appearing instantly:** + +```bash +> npx nx run todos:build + +> NX NOTE Cached Output: + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: c38fbdb8b372af447180 +Built at: 03/26/2020 11:05:06 AM +Entrypoint main = runtime.ff0534391bf88384547e.js main.b8dbcd3d3fd2900377f2.esm.js +Entrypoint polyfills = runtime.ff0534391bf88384547e.js polyfills.55535a35b1529d884ca3.esm.js +Entrypoint styles = runtime.ff0534391bf88384547e.js styles.3ff695c00d717f2d2a11.css +chunk {0} runtime.ff0534391bf88384547e.js (runtime) 0 bytes ={1}= ={2}= ={3}= [entry] [rendered] +chunk {1} main.b8dbcd3d3fd2900377f2.esm.js (main) 155 KiB ={0}= [initial] [rendered] +chunk {2} polyfills.55535a35b1529d884ca3.esm.js (polyfills) 239 KiB ={0}= [initial] [rendered] +chunk {3} styles.3ff695c00d717f2d2a11.css (styles) 147 bytes ={0}= [initial] [rendered] +``` + +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. + +## Building Multiple Projects + +**Now, run `npx nx run-many --target=build --projects=todos,api` to rebuild the two applications:** + +```bash +Nx read the output from cache instead of running the command for 1 out of 2 projects. +``` + +Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache [here](/{{framework}}/workspace/computation-caching). + +## --with-deps + +As we saw already, Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `npx nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> npx nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +> npx nx run ui:lint + +Linting "ui"... + +All files pass linting. + + +> npx nx run data:lint + +Linting "data"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `npx nx lint api --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 2 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/11-test-affected-projects.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/11-test-affected-projects.md new file mode 100644 index 0000000000..bdfb4147ae --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/11-test-affected-projects.md @@ -0,0 +1,78 @@ +# Step 11: Test Affected Projects + +## Video of this Lesson + + + +In addition to supporting computation caching, Nx can scale your development by doing code change analysis to see what can affected by a particular pull request. + +**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.tsx` and change the component:** + +```typescript jsx +import React from 'react'; +import { Todo } from '@myorg/data'; + +export const Todos = (props: { todos: Todo[] }) => { + return ( +
    + {props.todos.map((t) => ( +
  • {t.title}!!
    • + ))} +
+ ); +}; + +export default Todos; +``` + +**Run `npx nx affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps can be affected by this change. + +**Run `npx nx affected:libs`**, and 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 `npx nx affected:test` to retest only the projects affected by the change.** + +As you can see, since we updated the code, without updating the tests, the unit tests failed. + +```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. + +## 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 +``` + +!!!!! +Run "npx nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects with "invalid" were run +An error message saying that the "invalid" target is invalid diff --git a/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/12-summary.md b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/12-summary.md new file mode 100644 index 0000000000..eea36de8f0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/react/tutorial/12-summary.md @@ -0,0 +1,18 @@ +# Step 12: Summary + +In this tutorial you: + +- Built a full stack application using React and Express +- Shared code between the frontend and the backend +- Created a UI library +- Used Nx dep graph capabilities 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](/{{framework}}/cli/overview) +- [Computation Caching](/{{framework}}/workspace/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/guides/ci/monorepo-affected) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/affected.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/affected.png new file mode 100644 index 0000000000..4437f9a8e3 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/affected.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/all-cache-inputs.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/all-cache-inputs.png new file mode 100644 index 0000000000..e7e5bd839e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/all-cache-inputs.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/angular-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/angular-plugin.md new file mode 100644 index 0000000000..db1d1312c3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/angular-plugin.md @@ -0,0 +1,112 @@ +# Angular Plugin + +The Nx Plugin for Angular contains builders, schematics, and utilities for managing Angular applications, and libraries within an Nx workspace. It provides: + +- Integration with libraries such as Jest, Cypress, Karma, Protractor, and Storybook. +- Helper services, and functions to use along with NgRx libraries. +- Scaffolding for upgrading AngularJS applications. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the Angular plugin + +Adding the Angular plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/angular +``` + +```shell script +#npm +npm install -D @nrwl/angular +``` + +## Angular Projects in an Nx Workspace + +Building Angular applications within an Nx workspace is similar to building within a vanilla Angular CLI workspace, with a few differences. + +- Jest is used as the default unit test runner, configurable in the schematics section of the workspace configuration file. +- Cypress is used as the default E2E test runner, configurable in the schematics section of the workspace configuration. +- E2E tests are included in a separate project from the Angular application itself. +- The Nx CLI delegates common commands such as build, serve, test, lint, and e2e to the Angular CLI. + +The file structure for an Angular application looks like: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.scss +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── tslint.json +│   └── myapp-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tsconfig.json +│      └── tslint.json +├── libs/ +├── tools/ +├── angular.json +├── nx.json +├── package.json +├── tsconfig.json +├── tslint.json +└── README.md +``` + +## See Also + +- [Using DataPersistence](/{{framework}}/guides/misc-data-persistence) +- [Using NgRx](/{{framework}}/guides/misc-ngrx) +- [Upgrading an AngularJS application to Angular](/{{framework}}/guides/misc-angular) + +## Builders + +- [package](/{{framework}}/plugins/angular/builders/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Schematics + +- [application](/{{framework}}/plugins/angular/schematics/application) - Create an Angular application +- [downgrade-module](/{{framework}}/plugins/angular/schematics/downgrade-module) - Setup Downgrade Module +- [karma](/{{framework}}/plugins/angular/schematics/karma) - Add karma configuration to a workspace +- [karma-project](/{{framework}}/plugins/angular/schematics/karma-project) - Add karma testing to a project +- [library](/{{framework}}/plugins/angular/schematics/library) - Create an Angular library +- [move](/{{framework}}/plugins/angular/schematics/move) - Move an Angular application or library to another folder within the workspace +- [ngrx](/{{framework}}/plugins/angular/schematics/ngrx) - Add and use NgRx for state management +- [stories](/{{framework}}/plugins/angular/schematics/stories) - Create stories/specs for all components declared in a library +- [storybook-configuration](/{{framework}}/plugins/angular/schematics/storybook-configuration) - Setup configuration for Storybook +- [upgrade-module](/{{framework}}/plugins/angular/schematics/upgrade-module) - Add an upgrade module + +## Public API + +- DataPersistence - Angular Service that provides convenience methods for common operations of persisting data. +- fetch - Handles data fetching, and correct ordering of fetching using NgRx Effects +- navigation - Handles data fetching based on navigating to a certain component using NgRx Effects +- optimisticUpdate - Handles optimistic updates (updating the client first) using NgRx Effects. +- pessimisticUpdate - Handles pessimistic updates (updating the server first) fetching using NgRx Effects. + NxModule - An NgModule used to register the Angular providers, including DataPersistence. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/angular.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/angular.jpg new file mode 100644 index 0000000000..f03bf78a3b Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/angular.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/cypress.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/cypress.jpg new file mode 100644 index 0000000000..7727bf6d73 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/cypress.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/express.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/express.jpg new file mode 100644 index 0000000000..f55f7f0783 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/express.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/jest.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/jest.jpg new file mode 100644 index 0000000000..d7ce915a2a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/jest.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/nest.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/nest.jpg new file mode 100644 index 0000000000..9e02b1e3dd Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/nest.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/node.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/node.jpg new file mode 100644 index 0000000000..7003802217 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/node.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/react.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/react.jpg new file mode 100644 index 0000000000..e534bd5b24 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/react.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/api/web.jpg b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/web.jpg new file mode 100644 index 0000000000..d92cea331c Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/api/web.jpg differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/caching-example.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/caching-example.png new file mode 100644 index 0000000000..026252539a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/caching-example.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-everything-affected.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-everything-affected.png new file mode 100644 index 0000000000..95ea861c4e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-everything-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-one-affected.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-one-affected.png new file mode 100644 index 0000000000..1eb5a4c166 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph-one-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph.png new file mode 100644 index 0000000000..94138839ea Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/ci-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/build.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/10.4.13/shared/cli/e2e.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/e2e.md new file mode 100644 index 0000000000..1fdb16dc1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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 & autmatically 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/data-access-documents/src/data/10.4.13/shared/cli/generate.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/generate.md new file mode 100644 index 0000000000..033fcfd871 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/generate.md @@ -0,0 +1,93 @@ +# generate + +Runs a schematic that generates and/or modifies files based on a schematic from a collection. + +## Usage + +```bash +nx generate +``` + +```bash +nx g +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 schematics in the default collection. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/lint.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/10.4.13/shared/cli/run.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/10.4.13/shared/cli/serve.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/10.4.13/shared/cli/test.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/10.4.13/shared/computation-caching.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/computation-caching.md new file mode 100644 index 0000000000..ad15e517a8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/computation-caching.md @@ -0,0 +1,188 @@ +# Computation Caching + +It's costly to rebuild and retest the same code over and over again. Nx uses a computation cache to never rebuild the same code twice. When connected to Nx cloud, you can share the computation cache with everyone working on the same project. + +**In order not to recompute something twice, we need two things:** + +**1. We need to store the results of the computation.** +**2. We need to know when we are about to compute something we already computed before.** + +There are three things that tell Nx if something has been computed before: + +## Source Code Cache Inputs + +The result of building/testing an application or a library depends on the source code of that project and all the source codes of all the libraries it depends on (directly or indirectly). It also depends on the configuration files like `package.json`, `workspace.json`, `nx.json`, `tsconfig.json`, and `package-lock.json`. The list of these files isn't arbitrary. Nx can deduce most of them by analyzing our codebase. Few will have to be listed manually in the `implicitDependencies` property of `nx.json`. + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": { + "global-config-file.json": "*" + }, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"] + } + } + } +} +``` + +## Runtime Cache Inputs + +Things like the version of NodeJS, whether we are running Windows or not, can affect the results of the computation but cannot be deduced statically. Those will have to be configured manually too. + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": {}, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"], + "runtimeCacheInputs": ["node -v", "echo $IMPORTANT_ENV_VAR"] + } + } + } +} +``` + +## Args Cache Inputs + +Finally, in addition to Source Code Cache Inputs and Runtime Cache Inputs, Nx needs to consider the arguments. I.e., `nx build shop` and `nx build shop --prod` produce different results. + +Note, only the flags passed to the builder itself affect results of the computation. For instance, the following commands are identical from the caching perspective. + +```bash +nx build myapp --prod +nx build myapp --configuration=production +nx run-many --target=build --projects=myapp --configuration=production +nx run-many --target=build --projects=myapp --configuration=production --parallel +nx affected:build # given that myapp is affected +``` + +In other words, Nx does not cache what the developer types into the terminal. The args cache inputs consist of: Project Name, Target, Configuration + Args Passed to Builders. + +If you build/test/lint… multiple projects, each individual build will have its own cache value and will either be retrieved from cache or run. This means that from the caching point of view, the following command: + +```bash +nx run-many --target=build --projects=myapp1,myapp2 +``` + +is identical to the following two commands: + +```bash +nx build myapp1 +nx build myapp2 +``` + +## All Cache Inputs + +So the combination of Source Code Cache Inputs, Runtime Cache Inputs, and Args Cache Inputs determine the result of the computation. If anything in the source changes, Nx needs to recompute. If anything in runtime changes, Nx needs to recompute. But if we have already computed the results, we can simply use the stored artifacts. + +![all cache inputs](/shared/all-cache-inputs.png) + +## What is Cached + +Nx works on the process level. Regardless of the tools used to build/test/lint/etc.. your project, the results will be cached. + +Nx sets up hooks to collect stdout/stderr before running the command. All the output will be cached and then replayed during a cache hit. + +Nx will also cache the files generated by a command. The list of folders is listed in the outputs property in `workspace.json`. + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.tsx" + } + } + } + } +} +``` + +If the outputs property is missing, Nx will default to caching the appropriate folder in the dist (`dist/apps/myapp` for `myapp` and `dist/libs/somelib` for `somelib`). + +## Local Computation Memoization + +**Because the word "cache" appears in the description, the phrase "artifact caching" comes to mind. But this isn't the right way to think about it. What Nx does is computation memoization.** We can't choose to use or not use the cached value. There are no versions. It is transparent: Nx will skip the computation only when running the computation would have produced the same result. + +By default, Nx uses a local computation cache. The cache is stored in `node_modules/.cache/nx`. You can change the directory as follows: + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": {}, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"], + "cacheDirectory": "/tmp/nx" + } + } + } +} +``` + +Nx stores the cached values only for a week, after which they are deleted. To clear the cache, delete the cache directory, and Nx will create a new one next time it tries to access it. + +## Skipping Cache + +Sometimes you will want to skip the cache (e.g., if you are measuring the performance of a command). You can do it as follows + +```bash +nx build myapp --skip-nx-cache +nx affected:build --skip-nx-cache +``` + +## Nx Cloud and Distributed Computation Memoization + +Nx Cloud is a SAAS product that allows you to share the results of running build/test with everyone else working in the same workspace. Learn more at [https://nx.app](https://nx.app). + +## Example + +Say we are the first ones building some shop app. + +The `nx build` shop command will build the app by invoking webpack under the hood. It will create a hash key using the combination of `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs`. Nx then will check its local cache to see if this combination has already been built on this machine. If the answer is "no", it will check the Nx Cloud cache (if the workspace is connected to it) to see if someone else has already built it. If the answer is "no", it will run the build. + +It will set up hooks to collect stdout/stderr, and once the build is complete, it will store the command line output into a file in the local cache. It will also copy the produced files there as well. After that it will spawn a separate process to upload the artifacts to the Nx Cloud cache. + +If we rerun the same command, Nx will find the artifact in the local cache and will replay the output from it and will restore the necessary files. + +Imagine someone else on the team is trying to build `nx build shop`. As before Nx will use `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs` to get the computation hash key. It will then check the local cache. The result won't be there, so it will check the remote cache. **It will find the record there, so it will download it into its local cache first and then print the stored stdout/stderr and copy the files to the place where they would normally be created. The terminal output and the created files are exactly the same as if the person ran the computation themselves.** + +The "someone else" in this scenario doesn't have to be a real person. For instance, every CI run will likely use a different agent. When the agents can all access the same remote cache, the CI time goes down drastically. + +![cache example](/shared/caching-example.png) + +The `nx test shop` command, which in this case uses Jest, works similarly. The combination of `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs` determines the computation. The command won't emit any files, but the terminal output will be captured and stored. + +## Caching and Affected + +In addition to the memoization, which works against the current state of the codebase and the environment, Nx also is able to look at the code change itself (e.g., PR), and figure out what can be broken by it, and only rebuild and retest what is affected. Why use both? + +Affected and caching are used to solve the same problem: minimize the computation. But they do it differently, and the combination provides better results than one or the other. + +The affected command looks at the before and after states of the workspaces and figures out what can be broken by a change. Because it knows the two states, it can deduce the nature of the change. For instance, this repository uses React and Angular. If a PR updates the version of React in the root package.json, Nx will know that only half of the projects in the workspace can be affected. It knows what was changed--the version of React was bumped up. + +Caching simply looks at the current state of the workspace and the environment (e.g., version of Node) and checks if somebody already ran the command against this state. Caching knows that something changed, but because there is no before and after states, it doesn't know the nature of the change. In other words, caching is a lot more conservative. + +If we only use affected, the list of projects that will be retested is small, but if we test the PR twice, we will run all the tests twice. + +If we only use caching, the list of projects that will be retested is larger, but if we test the PR twice, we will only run tests the first time. + +Using both allows us to get the best of both worlds. The list of affected projects is as small as it can be, and we never run anything twice. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/console.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/console.md new file mode 100644 index 0000000000..bf20ceaf23 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/console.md @@ -0,0 +1,120 @@ +# Nx Console + +![Nx Console logo](/shared/nx-console-logo.png) + +**Spend less time looking up command line arguments and more time shipping incredible products.** + +- [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) + +With Nx, you can get a full-stack application up and running in minutes, no need to figure out source maps, webpack, test runners. It all works out of the box. Nx also helps you enforce consistent development practices by generating components, services, and state management modules. + +## Why Nx Console? + +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 schematic 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 + +For VSCode users, you can install the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) from Marketplace. + +## True UI for Nx + +Nx Console is the UI for Nx. It will work for any schematic 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, 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 schematic and then opens a form listing out all the options for that schematic. As you make changes to the form, the schematic is executed in `--dry-run` mode in a terminal so you can preview the results of running the schematic in real time. + + + +**From the Command Pallete** + +You can also launch the `Generate` action from the Command Palette (`⇧⌘P`) by selecting `nx: generate (ui)`. + + + +You can even construct the schematic options while staying entirely within the Command Palette. Use `⇧⌘P` to open the Command Palette, then select `nx: generate`. After choosing a schematic, select any of the listed options to modify the schematic command. When you're satified with the constructed command, choose the `Execute` command at the top of the list. + + + +### Run + +The `Run` action allows you to choose a builder command and then opens a form listing out all the options for that builder. The frequently used builder commands `build`, `serve`, `test`, `e2e` and `lint` also have their own dedicated actions. + + + +**From the Command Pallete** + +You can also construct the builder 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 builder command options. When you're satified 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 will navigate to that project's definition in the `workspace.json` (or `angular.json`) file. Clicking on the name of any builder command will navigate to that builder command's definition in the `workspace.json` (or `angular.json`) file. + +Clicking the [refresh-light.svg] icon next to the `PROJECTS` header will repopulate the Projects pane from the `workspace.json` (or `angular.json`) file. + +Clicking the [folder-light.svg] icon next to a project will reveal that project's folder in the VSCode Explorer pane. + +Clicking the [continue-light.svg] icon next to a builder command will execute 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/data-access-documents/src/data/10.4.13/shared/continue-light.svg b/nx-dev/data-access-documents/src/data/10.4.13/shared/continue-light.svg new file mode 100644 index 0000000000..2563bfa114 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/continue-light.svg @@ -0,0 +1,3 @@ + + + diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-logo.png new file mode 100644 index 0000000000..6553e4a03e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-plugin.md new file mode 100644 index 0000000000..0e6ed45540 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/cypress-plugin.md @@ -0,0 +1,92 @@ +# 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 + +## How to Use 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 +``` + +```treeview +/ +├── apps/ +│   ├── frontend/ +│   └── frontend-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── nx.json +├── package.json +├── README.md +├── workspace.json +└── tsconfig.json +``` + +### 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, `ng 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). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/dependency-graph.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/dependency-graph.png new file mode 100644 index 0000000000..7c187112fb Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/dependency-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/distributed-builds.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/distributed-builds.md new file mode 100644 index 0000000000..2788c8fd29 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/distributed-builds.md @@ -0,0 +1,14 @@ +# 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. + +The `print-affected` and `run-many` commands can be used to set up your CI to use multiple agents, while still rebuilding and retesting only what is affected. + +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). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/examples/nx-examples.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/examples/nx-examples.md new file mode 100644 index 0000000000..fc01b63367 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/examples/nx-examples.md @@ -0,0 +1,9 @@ +# 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/data-access-documents/src/data/10.4.13/shared/express-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/express-plugin.md new file mode 100644 index 0000000000..997e2fbb7a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/express-plugin.md @@ -0,0 +1,128 @@ +# Express Plugin + +The Express plugin contains schematics to add a new Express application to an Nx workspace. + +## Adding the Express plugin + +Adding the Express plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/express +``` + +```shell script +#npm +npm install -D @nrwl/express +``` + +> Note: You can create new workspace that has Express and React set up by doing `npx create-nx-workspace@latest --preset=react-express` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/express:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ + └── express-app/ +    ├── jest.config.js +    ├── src/ +    │   ├── app/ +    │   ├── assets/ +    │   ├── environments/ +    │   │   ├── environment.prod.ts +    │   │   └── environment.ts +    │   └── main.ts +    ├── tsconfig.app.json +    ├── tsconfig.json +    ├── tsconfig.spec.json +   └── tslint.json +``` + +The `main.ts` content should look similar to this: + +```typescript +import * as express from 'express'; + +const app = express(); + +app.get('/api', (req, res) => { + res.send({ message: 'Welcome to express-app!' }); +}); + +const port = process.env.port || 3333; +const server = app.listen(port, () => { + console.log(`Listening at http://localhost:${port}/api`); +}); +server.on('error', console.error); +``` + +#### Application Proxies + +Generating Express applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/express:application --frontendProject my-react-app +``` + +### Application commands + +When a Express application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Express application to be rebuilt automatically. +Express applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://expressjs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +##### Waiting for other builds + +Setting the `waitUntilTargets` option with an array of projects (with the following format: `"project:architect"`) will execute those commands before serving the Express application. + +#### lint + +The lint command will run linting within the scope of the Express app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Express app. + +```shell script +nx test +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/folder-light.svg b/nx-dev/data-access-documents/src/data/10.4.13/shared/folder-light.svg new file mode 100644 index 0000000000..8daecdac6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/folder-light.svg @@ -0,0 +1,3 @@ + + + diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/guides/browser-support.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/guides/browser-support.md new file mode 100644 index 0000000000..1dba1fbc7d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/guides/browser-support.md @@ -0,0 +1,70 @@ +# 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 schematics ship an aggressively modern browser support config, in the form of a `.browserlistrc` file in the root of the application with the following contents. + +``` +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: + +``` +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 application directory to get an output of browsers and versions to support. + +```sh +$ 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: + +```sh +npx browserslist '> 0.5%, not IE 11' +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/incremental-builds.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/incremental-builds.md new file mode 100644 index 0000000000..dde7950249 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/incremental-builds.md @@ -0,0 +1,56 @@ +# Incremental Builds + +Building applications incrementally is one of the main ways to scale your development as your applications getting bigger. + +For instance, say we generate an application and a library, and then import the library from the application: + +```bash +nx g @nrwl/react:app myapp +nx g @nrwl/react:lib mylib +``` + +In this case `mylib` isn't a buildable library. We can test and lint it independently, but the only way to build it is by building some application using it (in this case `myapp`). For small and medium size applications this provides the best dev experience because WebPack is optimized for this scenario. But as your application keeps growing, the dev experience degrades. + +## Buildable Libraries + +Now let's create a buildable library instead (you can always make an existing library buildable after the fact). + +```bash +nx g @nrwl/react:app myapp +nx g @nrwl/react:lib mylib --buildable +``` + +Every buildable library has a build task: + +```json +{ + "build": { + "builder": "@nrwl/web:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "project": "libs/mylib/package.json", + "entryFile": "libs/mylib/src/index.ts", + "external": ["react", "react-dom"], + "babelConfig": "@nrwl/react/plugins/bundle-babel", + "rollupConfig": "@nrwl/react/plugins/bundle-rollup" + } + } +} +``` + +When building the app, we need to first run `nx build mylib` and then `nx build myapp`. As the number of libraries grows, running these commands quickly becomes unworkable. Instead, we can run `nx build myapp --with-deps`. + +Running `nx build myapp --with-deps` is basically the same as running `nx run-many --target=build --projects=myapp --with-deps`. Nx will look at all the dependencies of `myapp`, and will build them in the right order. So if say some `parentlib` depends on `childlib`, `childlib` will be built first. Nx will build whatever it can in parallel. + +When using buildable libraries, the application doesn't depend on the source code of the library. Instead, it depends on the compiled output. This is what lets you save a lot of time and make your builds fast. + +## Incremental Builds and Cache + +It's costly to rebuild all the buildable libraries from scratch every time you want to serve the app. That's why the Nx computation caching is so important. The caching allows us to only rebuild a small subset of the libraries, which results in much better performance. + +If we can share the cache with our teammates, we can get a much better dev experience. For instance, [this repo](https://github.com/nrwl/nx-incremental-large-repo) has a large application, where `nx serve` takes just a few seconds. Check out [nx.app](https://nx.app) for more information on how to do it. + +## Restrictions + +- Buildable libraries can only depend on other buildable libraries. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-logo.png new file mode 100644 index 0000000000..ac0c0f5e44 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-plugin.md new file mode 100644 index 0000000000..a85dc68adb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/jest-plugin.md @@ -0,0 +1,110 @@ +# Jest Plugin + +![Jest logo](/shared/jest-logo.png) + +[Jest](https://jestjs.io/) is an open source test runner created by Facebook. It is used within Facebook internally as well as many other enterprise and open source projects including Nx itself! + +## Reasons for Using Jest + +- Jest was built with monorepos in mind and is able to isolate the important parts of a monorepo to test. +- Jest has a great built-in reporter for printing out results of tests. +- Jest has an immersive watch mode which provides near instant feedback when developing tests. +- Jest provides the ability to use Snapshot Testing to validate features. +- And more... + +## How to use Jest + +By default, Nx will use Jest when creating applications and libraries. + +```treeview +/ +├── apps/ +│   ├── frontend/ +│   │   ├── src/ +│   │   ├── browserslist +│   │   ├── jest.config.js # <== jest config +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   └── tsconfig.spec.json +│   └── frontend-e2e/ +├── libs/ +├── tools/ +├── nx.json +├── package.json +├── README.md +├── workspace.json +└── tsconfig.json +``` + +Depending on the project you are creating, Nx can support other test runners in addition to Jest. You can configure the test runner you use by passing `--unit-test-runner=jest` when creating applications or libraries. + +### Running Tests + +```bash +nx test frontend +``` + +### Snapshot Testing + +Jest has support for **Snapshot Testing**, a tool which simplifies validating data did not change. Check out the [official Jest Documentation on Snapshot Testing](https://jestjs.io/docs/en/snapshot-testing). + +#### Writing Tests Using Snapshot Testing + +To write a test which uses **Snapshot Testing**, use the `toMatchSnapshot()` matcher. + +```typescript +describe('Home Page', () => { + it('should have a header', () => { + const header = renderHeader(); + expect(header).toMatchSnapshot(); + }); +}); +``` + +The snapshot will be generated the first time the test is run. If the contents of that snapshot change, the test will fail indicating unexpected changes to the snapshot. Below is an example of the test results if the hamburger icon disappears unintentionally. + +```bash +Home Page > should have a header + expect(value).toMatchSnapshot() + Received value does not match stored snapshot "Home Page should have a header 1". + - Snapshot ++ Received +
+

+- +- hamburger +- + Example +

+
+``` + +> Note: These snapshot files should be checked in with your code. + +#### Updating Snapshots + +When intentionally changing the contents of a snapshot, you can run tests with the `--updateSnapshot` flag to update failing snapshots instead of failing the test. + +```bash +nx test libname --updateSnapshot +``` + +> Make sure no **unintentional** snapshots are failing **BEFORE** updating failing snapshots. + +### Watching for Changes + +If you are a developer making changes locally to a library, start jest's interactive watch mode to run the library's tests related to uncommitted changes and then rerun tests whenever files are changed. + +```bash +nx test libname --watch +``` + +#### Debugging Failing Tests + +To debug failing tests using Chrome Devtools or an IDE you can run the test command through node's `--inspect-brk` flag. + +```bash +node --inspect-brk ./node_modules/nx/bin/nx test libname +``` + +Now, you can visit [chrome://inspect](chrome://inspect) in Chrome and inspect the target to attach to the node process. You can now use Chrome Devtools to step through your code line by line and debug the cause of the failing tests. Visit the official [Jest documentation](https://jestjs.io/docs/en/troubleshooting#tests-are-failing-and-you-don-t-know-why) to find out more. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/overview.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/overview.md new file mode 100644 index 0000000000..36a7d1bf6b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/overview.md @@ -0,0 +1,189 @@ +# Migrating existing code bases + +## What you’ll accomplish + +Migrating into an Nx workspace can seem intimidating. While every codebase is unique, we can offer recommendations for how to proceed based on the Nrwl team’s years of experience. The key to success is an incremental approach. You don’t need to migrate your entire codebase at once. Find a good target for migration, move it into your Nx workspace, get it working and stable, and go from there. + +This document will introduce you to the Nx workspace, help you get one created, and point you to some particular configuration that you may need for your codebase. + +## Create a workspace + +To get started, you’ll need an Nx workspace. While Nx offers several preset configurations for your workspace, we recommend starting migration with an `empty` workspace. This will allow you to have finer control over the configuration and creation of the applications and libraries in your workspace. + +To create an empty workspace: + +```bash +npx create-nx-workspace@latest +``` + +Select `empty` when prompted: + +```bash +? What to create in the new workspace (Use arrow keys) +❯ empty [an empty workspace] +``` + +## Exploring your workspace + +Take a tour of your [Nx workspace](/{{framework}}/workspace/workspace-overview). There are some important areas to know about as you migrate. + +### apps + +The `apps` directory is the place where your top-level applications will be stored. You should always begin your migration journey by adding an application. + +For Angular applications: + +```bash +nx generate @nrwl/angular:application my-application +``` + +For React applications: + +```bash +nx generate @nrwl/react:application my-application +``` + +There are a lot of options when creating your application. If you want to follow Nx recommendations, you can accept the defaults. If you have a well-established codebase, you can configure those options at the time of application generation. You can find documentation for these options for the different frameworks here: + +- [Angular](/{{framework}}/plugins/angular/schematics/application) +- [React](/{{framework}}/plugins/react/schematics/application) + +You may also find it useful to use the [Nx Console](/{{framework}}/cli/console) in Visual Studio Code. This will give you a visual way to generate your application with all of the options laid out in front of you. + +### Configuration files + +Your workspace contains different configuration files for the tools you’ll need to develop, such as linters, bundlers, and builders. There are two sources of configuration files for your workspace: at the root of the workspace and at the root of your application. The configuration files at the root of your application extend the configuration files found at the root of your workspace. If you need to make global adjustments to these configurations, you should do so at the root of the workspace. If you have multiple applications that need different configurations, you should manage this using the configuration files in the root of each application. + +In general, you should not replace the configuration files provided for you. You should add to or modify the configurations that are there. This will help ensure that your configuration files are set up for Nx to work at its best. + +### Nx Configuration Files + +In addition to configuration files for external libraries, your Nx workspace will have configuration files for Nx itself. This will be `angular.json` for workspaces using the Angular CLI and `workspace.json` for workspaces using the Nx CLI. This file will define all of the individual projects in your workspace (of which your application is one) and the tasks available for them. + +For example, your generated application should have four [tasks available]({{framework}}/workspace/builders/using-builders) for it: `build`, `serve`, `lint`, and `test`. Each of these comes with its own configuration. If you find you need to adjust the configuration of a task for your codebase, this is the place to begin looking. + +These workspace configuration files can seem a little long and intimidating. The Nx Console can help you navigate it more easily with its Workspace JSON panel. By clicking on a project in your workspace, it will navigate you to the right place in the workspace file to begin making edits. + +Additionally, there is an `nx.json` file that contains metadata about your projects. [This metadata includes tags]({{framework}}/workspace/structure/monorepo-tags) that can help you impose constraints on your applications and library dependencies. + +## Migrating your code + +There are two major steps to migrating your application: migrating your dependencies and migrating your code. + +### Dependencies + +If you’re already using npm for package management, this is as easy as copying your dependencies from your old `package.json` file to your workspace’s `package.json`. Make sure you don’t add any duplicate dependencies during this step. + +If you’re using other package managers such as Bower, you’ll need to take an intermediary step of moving your dependencies from there to NPM. For Bower, [migration information is available](https://bower.io/blog/2017/how-to-migrate-away-from-bower/) + +### Code + +If your code is all in a single app, you can copy it into the application’s folder. Configuration files go in the root of your application, and application code goes into the `src/app` folder. Assets such as images, icons, and fonts can go into the `src/assets` directory. An `index.html` is provided for you in `src`. You should add anything else you may need such as external fonts or icons from a CDN. `src/main.ts` will bootstrap your application. You may need to modify this file or modify your application file names to bootstrap your app. + +## Running tasks + +Now that your code is present, it’s time to tackle building and testing it. + +Local build and serve +Each generated application has a build process defined by Nx. This uses the Angular CLI for Angular, and webpack is used for all other projects. See if this build process works out of the box for you by running + +```bash +nx serve my-application +``` + +If this doesn’t work for you, you may need to add or modify some configuration on the `build` task in your workspace configuration file. + +[Learn more about local serving](/{{framework}}/cli/serve) + +### Unit tests + +Each application will have a unit test process defined by your choices (Jest or Karma) during the creation of the application. To run tests for your application: + +```bash +nx test my-application +``` + +It is recommended that unit tests live next to the code they exercise and code scaffolded by Nx will follow this pattern. If your unit tests currently live in a separate directory, you may need to modify your test configuration or move your test files. + +Testing configuration files can be found in the root of your application as well as the workspace configuration file. + +[Learn more about unit testing](/{{framework}}/cli/test) + +### End to End Tests + +Each application will have an e2e configuration created as a separate application, appended with `-e2e`. In our example, you’ll see `my-application-e2e`. This `e2e` task uses the test runner you chose during generation, Protractor or Cypress. Your application’s e2e tests should be migrated to this directory. There will be an e2e test scaffolded for you to make sure everything works before you start adding your own. To run the e2e tests: + +```bash +nx e2e my-application-e2e +``` + +All of the configuration for your e2e tests should be in this directory. + +[Learn more about end-to-end testing](/{{framework}}/cli/e2e) + +### Linting + +Nx uses either tslint or eslint for linting, based on your application’s configuration. Nx also has its own lint process to make sure your Nx configuration is valid. + +To run the `lint` task for your workspace + +```bash +nx lint +``` + +To run the `lint` task for a particular application: + +```bash +nx lint my-application +``` + +Global configuration files for linting will be at the root of your workspace. Each application and library will extend those configuration files. Global configuration changes should be made in the root, while application-or-library-specific changes should occur in the application or library configuration files. + +[Learn more about linting](/{{framework}}/cli/lint) + +### Formatting + +Nx uses Prettier to ensure standard formatting across your codebase. Prettier configuration files are located in the root of the workspace. To format your workspace run: + +```bash +nx format:write +``` + +[Learn more about formatting](/{{framework}}/cli/format-write) + +### Adding tasks + +Nx offers built-in tasks for the most common needs: `serve`, `build`, `test`, `e2e`, and `lint`. You likely have additional tasks that are needed to manage or deploy your codebase. These tasks might include deployment, i18n workflows, or uploading assets to CDNs. These tasks can be set up as scripts that you run manually with node, ts-node, or npm scripts. You can migrate those tasks over as-is, to begin with. + +You should consider implementing them as Nx tasks which should be a quick transition with the `run-commands` builder. [The `run-commands` builder](/{{framework}}/workspace/builders/run-commands-builder) will allow you to run any custom commands you need as an Nx task. By implementing these commands in an Nx task, they are able to take advantage of the dependency graph in Nx and only run when necessary. They are also able to be cached and only be re-run when necessary. + +Your use-case may also be covered by one of our community plugins. Plugin authors are able to extend the functionality of Nx through our plugin API. + +[Learn more about the `run-commands` builder](/{{framework}}/plugins/workspace/builders/run-commands) + +[Learn more about caching](/{{framework}}/workspace/computation-caching) + +[Learn more about community plugins](/nx-community) + +## Migrating libraries + +If your code is divided into libraries, you should also generate libraries for your code to migrate into: + +For Angular libraries: + +```bash +nx generate @nrwl/angular:library +``` + +For React libraries: + +```bash +nx generate @nrwl/react:library +``` + +It’s important to remember: don’t just drop your code anywhere! Always generate an app or a library for that code before migration. Without the project configuration, you’ll miss out on key functionalities of Nx provided by the dependency graph generation and affected code detection. + +Establishing code boundaries +If you’re consolidating multiple repositories or libraries into a single Nx workspace, you may have concerns about code boundaries. Previously, you may have had well-established boundaries by separating code into different repositories or having a public API for a library. Nx features a tagging system that allows you to enforce these code boundaries in a granular way. Each project can be tagged, and you can constrain dependencies based on these tags. + +[Learn more about tags and dependency constraints](/{{framework}}/workspace/structure/monorepo-tags) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/preserving-git-histories.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/preserving-git-histories.md new file mode 100644 index 0000000000..761db22841 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/migration/preserving-git-histories.md @@ -0,0 +1,39 @@ +# Preserving Git Histories When Migrating Other Projects to Your Nx Workspace + +The nature of a mono-repo is to swallow up stand-alone projects as your organization buys into the benefits of a mono-repo workflow. + +As your mono-repo consumes other projects though, it's important to ensure that git history for those projects is preserved inside of our Nx Workspace. + +Git has some helpful tools for this, and we'll walk through some of the common pitfalls and gotchas of this task! + +## Merging In a Standalone Project + +To merge in another project, we'll essentially use the standard `git merge` command, but with a few lesser known options/caveats. + +To start we'll add a remote repository url for where the standalone app is located: + +```bash +git remote add my-stand-alone-app +``` + +Assuming that our main branch on this repo is called 'master', then we'll run + +```bash +git merge my-stand-alone-app/master --allow-unrelated-histories +``` + +Note that without the `--allow-unrelated-histories` option, the command would fail with the message: `fatal: refusing to merge unrelated histories`. + +## Merge Conflicts + +At this point, it is very likely that you'll have merge conflicts in your root files. + +For your `package-lock.json` or `yarn.lock`, it's likely best to remove those entirely and allow a new lock file to be generated by installing when the merge is complete. + +For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. + +Note that for these files, the file-history of the stand-alone project will be not be present after merging. You would see all changes from resolving conflicts in the single merge commit, and any further back would simply be the file history of your workspace. + +## Using `git mv` + +Especially if your stand-alone project was not an Nx workspace, it's likely that your migration work will also entail moving around directories to match a typical Nx Workspace structure. You can find more information in the [Overview](/{{framwork}}/migration/overview) page, but when migrating an existing project, you'll want to ensure that you use [`git mv`](https://git-scm.com/docs/git-mv) when moving a file or directory to ensure that file history from the old standalone repo is not lost! diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-affected.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-affected.md new file mode 100644 index 0000000000..6ef0f1e58c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-affected.md @@ -0,0 +1,194 @@ +# Rebuilding and Retesting What is Affected + +When using Nx you can build and test individual apps and libs. + +```bash +nx g @nrwl/web:app client +nx g @nrwl/web:app admin +nx g @nrwl/workspace:lib client-feature-main +nx g @nrwl/workspace:lib admin-feature-permissions +nx g @nrwl/workspace:lib components-shared + +nx build client +nx build client-feature-main # works if the lib is marked as publishable + +nx test client +nx test admin +nx test client-feature-main +nx e2e client-e2e +``` + +Now imagine, `admin` depends on `admin-feature-permissions`. If we make a change to `admin-feature-permissions`, we not only need to make sure that `admin-feature-permissions` still functions as intended. We also need to make sure nothing that depends on `admin-feature-permissions` such as `admin` is broken unintentionally. + +Typically, you would do it like this: + +```bash +nx test admin-feature-permissions +nx build admin +nx test admin +nx e2e admin-e2e +``` + +In many organizations, you would have dozens or hundreds of apps and libs. To be productive in a monorepo, you need to be able to check that your change is safe, and rebuilding and retesting everything on every change won't scale, tracing the dependencies manually (as shown above) won't scale either. + +Because Nx has built-in computation caching, you could retest and rebuild everything on every commit: + +```bash +nx run-many --target=test --all +nx run-many --target=lint --all +nx run-many --target=e2e --all +nx run-many --target=build --all +``` + +If you use [Nx Cloud](https://nx.app), this can be a viable option. + +## Code Changes Analysis + +In addition to computation caching, Nx supports code change analysis. Nx uses code analysis to construct a dependency graph of all projects in the workspace. It then uses the dependency graph to determine what needs to be rebuilt and retested based on what you changed in a git branch. + +## Viewing Dep Graph + +Run `nx dep-graph` to see the dependency graph. + +![dependency-graph](/shared/dependency-graph.png) + +## Affected + +Affected projects are projects that are impacted by a set of changes. In order to find out which projects could be impacted by a particular change, Nx first determines which projects own the changed files. These projects are definitely impacted because they had changes made directly to them. Projects that consume projects which are directly changed may also be impacted by these changes. As a result, those projects must be tested as well to verify that all changes in behavior are identified. + +To calculate the project affected by your change, Nx needs to know what file you changed. The most direct way to do it is by passing `--files`: + +```bash +nx affected:dep-graph --files=libs/admin-feature-permissions/src/index.ts +``` + +![dependency-graph-affected](/shared/affected.png) + +In practice, it's easier to use git to determine what files have changed. + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +The `--base` defaults to `master` and `--head` defaults to `HEAD`, so when running it locally you can usually omit it: + +```bash +nx affected:dep-graph +``` + +Nx will find the most common ancestor of the base and head SHAs and will use it to determine what has changed between it and head. + +## Building/Testing/Printing Affected Projects + +```bash +nx affected:apps # prints affected apps +nx affected:libs # prints affected libs +nx affected:build # builds affected apps and libs +nx affected:lint # lints affected apps and libs +nx affected:test # tests affected apps and libs +nx affected:e2e # e2e tests affected apps +``` + +All of these are just shortcuts for the following: + +```bash +nx affected --target=ANYTARGET # run ANYTARGET for all affected apps and libs +``` + +## CI + +The SHAs you pass must be defined in the git repository. The `master` and `HEAD` SHAs are what you normally use while developing. Most likely you will want to provision other SHAs in your CI environment. + +```bash +nx affected:build --base=origin/master --head=$PR_BRANCH_NAME # where PR_BRANCH_NAME is defined by your CI system +nx affected:build --base=origin/master~1 --head=origin/master # rerun what is affected by the last commit in master +``` + +## When Nx can't Understand Your Repository + +Nx uses its advanced code analysis to construct a dependency graph of all applications and libraries. Some dependencies, however, cannot be determined statically. But you can define them yourself in `nx.json`. + +```json +{ + "npmScope": "myorg", + "implicitDependencies": { + "package.json": "*", + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "client": { + "tags": [], + "implicitDependencies": [] + }, + "client-e2e": { + "tags": [], + "implicitDependencies": ["client"] + }, + "admin": { + "tags": [], + "implicitDependencies": [] + }, + "admin-e2e": { + "tags": [], + "implicitDependencies": ["admin"] + }, + "client-feature-main": { + "tags": [], + "implicitDependencies": [] + }, + "admin-feature-permissions": { + "tags": [], + "implicitDependencies": [] + }, + "components-shared": { + "tags": [], + "implicitDependencies": [] + } + } +} +``` + +The `implicitDependencies` map is used to define what projects are affected by global files. In this example, any change to `package.json` will affect all the projects in the workspace, so all of them will have to be rebuilt and retested. You can replace `*` with an explicit list of projects. + +```json +{ + "implicitDependencies": { + "package.json": ["admin", "client"], + "tsconfig.json": "*", + "nx.json": "*" + } +} +``` + +You can also specify dependencies between projects. For instance, if `admin-e2e` tests both the `admin` and `client` applications, you can express this as follows: + +```json +{ + "admin-e2e": { + "tags": [], + "implicitDependencies": ["client", "admin"] + } +} +``` + +### Ignoring Additional Files from Affected Commands + +Nx provides two methods to exclude additional glob patterns (files and folders) from `affected:*` commands. + +- Glob patterns defined in your `.gitignore` file are ignored. +- Glob patterns defined in an optional `.nxignore` file are ignored. + +## Caching and Affected + +Affected and caching are used to solve the same problem: minimize the computation. But they do it differently, and the combination provides better results than one or the other. + +The affected command looks at the before and after states of the workspaces and figures out what can be broken by a change. Because it knows the two states, it can deduce the nature of the change. For instance, this repository uses React and Angular. If a PR updates the version of React in the root package.json, Nx will know that only half of the projects in the workspace can be affected. It knows what was changed--the version of React was bumped up. + +Caching simply looks at the current state of the workspace and the environment (e.g., version of Node) and checks if somebody already ran the command against this state. Caching knows that something changed, but because there is no before and after states, it doesn't know the nature of the change. In other words, caching is a lot more conservative. + +If we only use affected, the list of projects that will be retested is small, but if we test the PR twice, we will run all the tests twice. + +If we only use caching, the list of projects that will be retested is larger, but if we test the PR twice, we will only run tests the first time. + +Using both allows us to get the best of both worlds. The list of affected projects is as small as it can be, and we never run anything twice. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-azure.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-azure.md new file mode 100644 index 0000000000..464c20fa73 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-azure.md @@ -0,0 +1,283 @@ +# Distributed CI Using Azure Pipelines + +Nx is a set of extensible dev tools for monorepos. 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 +- ... + +But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. + +## Example Workspace + +[This repo](https://github.com/nrwl/nx-azure-build) is an example Nx Workspace. It has two applications. Each app has 15 libraries, each of which consists of 30 components. The two applications also share code. + +If you run `nx dep-graph`, you will see somethign like this: + +![dependency-graph](/shared/ci-graph.png) + +### CI Provider + +This example will use Azure Pipelines, but a very similar setup will work with CircleCI, Jenkins, GitLab, etc.. + +### **To see CI runs click [here](https://dev.azure.com/nrwlio/nx-azure-ci/_build?definitionId=6&_a=summary).** + +## Baseline + +Most projects that don't use Nx end up building, testing, and linting every single library and application in the repository. The easiest way to implement it with Nx is to do something like this: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx run-many --target=test --all + - script: yarn nx run-many --target=lint --all + - script: yarn nx run-many --target=build --all --prod +``` + +This will retest, relint, rebuild every project. Doing this for this repository takes about 45 minutes (note that most enterprise monorepos are significantly larger, so in those cases we are talking about many hours.) + +The easiest way to make your CI faster is to do less work, and Nx is great at that. + +## Building Only What is Affected + +Nx knows what is affected by your PR, so it doesn't have to test/build/lint everything. Say the PR only touches `ng-lib9`. If you run `nx affected:dep-graph`, you will see something like this: + +![dependency-graph one library affected](/shared/ci-graph-one-affected.png) + +If you update `azure-pipelines.yml` to use `nx affected` instead of `nx run-many`: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx affected --target=test --base=origin/master + - script: yarn nx affected --target=lint --base=origin/master + - script: yarn nx affected --target=build --base=origin/master --prod +``` + +the CI time will go down from 45 minutes to 8 minutes. + +This is a good result. It helps to lower the average CI time, but doesn't help with the worst case scenario. Some PR are going to affect a large portion of the repo. + +![dependency-graph everything affected](/shared/ci-graph-everything-affected.png) + +You could make it faster by running the commands in parallel: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + variables: + IS_PR: $[ eq(variables['Build.Reason'], 'PullRequest') ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx affected --target=test --base=origin/master --parallel + - script: yarn nx affected --target=lint --base=origin/master --parallel + - script: yarn nx affected --target=build --base=origin/master --prod --parallel +``` + +This helps but it still has a ceiling. At some point, this won't be enough. A single agent is simply insufficent. You need to distribute CI across a grid of machines. + +## Distributed CI + +To distribute you need to split your job into multiple jobs. + +``` + + / lint1 +Prepare Distributed Tasks - lint2 + - lint3 + - test1 + .... + \ build3 + +``` + +### Distributed Setup + +The `distributed_tasks` job figures out what is affected and what needs to run on what agent. + +```yaml +jobs: + - job: distributed_tasks + pool: + vmImage: 'ubuntu-latest' + variables: + IS_PR: $[ eq(variables['Build.Reason'], 'PullRequest') ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - powershell: echo "##vso[task.setvariable variable=COMMANDS;isOutput=true]$(node ./tools/scripts/calculate-commands.js $(IS_PR))" + name: setCommands + - script: echo $(setCommands.COMMANDS) + name: echoCommands +``` + +Where `calculate-commands.js` looks like this: + +```javascript +const execSync = require('child_process').execSync; +const isMaster = process.argv[2] === 'False'; +const baseSha = isMaster ? 'origin/master~1' : 'origin/master'; + +// prints an object with keys {lint1: [...], lint2: [...], lint3: [...], test1: [...], .... build3: [...]} +console.log( + JSON.stringify({ + ...commands('lint'), + ...commands('test'), + ...commands('build'), + }) +); + +function commands(target) { + const array = JSON.parse( + execSync(`npx nx print-affected --base=${baseSha} --target=${target}`) + .toString() + .trim() + ).tasks.map((t) => t.target.project); + + array.sort(() => 0.5 - Math.random()); + const third = Math.floor(array.length / 3); + const a1 = array.slice(0, third); + const a2 = array.slice(third, third * 2); + const a3 = array.slice(third * 2); + return { + [target + '1']: a1, + [target + '2']: a2, + [target + '3']: a3, + }; +} +``` + +Let's step through it: + +The following defines the base sha Nx uses to execute affected commands. + +```javascript +const isMaster = process.argv[2] === 'False'; +const baseSha = isMaster ? 'origin/master~1' : 'origin/master'; +``` + +If it is a PR, Nx sees what has changed compared to `origin/master`. If it's master, Nx sees what has changed compared to the previous commit (this can be made more robust by remembering the last successful master run, which can be done by labeling the commit). + +The following prints information about affected project that have the needed target. `print-affected` doesn't run any targets, just prints information about them. + +```javascript +execSync(`npx nx print-affected --base=${baseSha} --target=${target}`) + .toString() + .trim(); +``` + +The rest of the `commands` splits the list of projects into three groups or bins. + +### Other Jobs + +Other jobs use the information created by `distributed_tasks` to execute the needed tasks. + +```yaml +- job: lint1 + dependsOn: distributed_tasks # this tells lin1 to wait for distributed_tasks to complete + condition: | + and( + succeeded(), + not(contains( + dependencies.distributed_tasks.outputs['setCommands.COMMANDS'], + '"lint1":[]' + )) + ) + pool: + vmImage: 'ubuntu-latest' + variables: + COMMANDS: $[ dependencies.distributed_tasks.outputs['setCommands.COMMANDS'] ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: node ./tools/scripts/run-many.js '$(COMMANDS)' lint1 lint +``` + +where `run-many.js`: + +```javascript +const execSync = require('child_process').execSync; + +const commands = JSON.parse(process.argv[2]); +const projects = commands[process.argv[3]]; +const target = process.argv[4]; +execSync( + `npx nx run-many --target=${target} --projects=${projects.join( + ',' + )} --parallel`, + { + stdio: [0, 1, 2], + } +); +``` + +### Artifacts + +This example doesn't do anything with the artifacts created by the build, but often you will need to upload/deploy them. There are several ways to handle it. + +1. You can create a job per application and then copy the output to the staging area, and then once tests complete unstage the files in a separate job and then deploy them. +2. You can use the outputs property from running `npx nx print-affected --target=build` to stash and unstash files without having a job per app. + +```json +{ + "tasks": [ + { + "id": "react-app:build", + "overrides": {}, + "target": { + "project": "react-app", + "target": "build" + }, + "command": "npm run nx -- build react-app", + "outputs": [ + "dist/apps/react-app" + ] + }, + { + "id": "ng-app:build", + "overrides": {}, + "target": { + "project": "ng-app", + "target": "build" + }, + "command": "npm run nx -- build ng-app", + "outputs": [ + "dist/apps/ng-app" + ] + } + ], + "dependencyGraph": { + ... + } +} +``` + +### Improvements + +With these changes, rebuild/retesting/relinting everything takes only 7 minutes. The average CI time is even faster. The best part of this is that you can add more agents to your pool when needed, so the worst-case scenario CI time will always be under 15 minutes regardless of how big the repo is. + +### Can We Do Better? + +This example uses a fixed agent graph. This setup works without any problems for all CI providers. It also scales well for repo of almost any size. So before doing anything more sophisticated, I'd try this approach. Some CI providers (e.g., Jenkins) allow scaling the number of agents dynamically. The `print-affected` and `run-many` commands can be used to implement those setups as well. + +## Summary + +1. Rebuilding/retesting/relinting everyting on every code change doesn't scale. **In this example it takes 45 minutes.** +2. Nx lets you rebuild only what is affected, which drastically improves the average CI time, but it doesn't address the worst-case scenario. +3. Nx helps you run multiple targets in parallel on the same machine. +4. Nx provides `print-affected` and `run-many` which make implemented distributed CI simple. **In this example the time went down from 45 minutes to only 7** diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-jenkins.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-jenkins.md new file mode 100644 index 0000000000..3b31d0fc19 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-ci-jenkins.md @@ -0,0 +1,287 @@ +# Distributed CI Using Jenkins + +Nx is a set of extensible dev tools for monorepos. 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 +- ... + +But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. + +## Example Workspace + +[This repo](https://github.com/nrwl/nx-jenkins-build) is an example Nx Workspace. It has two applications. Each app has 15 libraries, each of which consists of 30 components. The two applications also share code. + +If you run `nx dep-graph`, you will see somethign like this: + +![dependency-graph](/shared/ci-graph.png) + +### CI Provider + +This example will use Jenkins. An [azure pipelines example](https://github.com/nrwl/nx-azure-build) is here, but it should not be too hard to implement the same setup on other platforms. + +## Baseline + +Most projects that don't use Nx end up building, testing, and linting every single library and application in the repository. The easiest way to implement it with Nx is to do something like this: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx run-many --target=test --all' + } + + stage("Lint") { + sh 'yarn nx run-many --target=lint --all' + } + + stage("Build") { + sh 'yarn nx run-many --target=build --all --prod' + } + } + } +} +``` + +This will retest, relint, rebuild every project. Doing this for this repository takes about 45 minutes (note that most enterprise monorepos are significantly larger, so in those cases we are talking about many hours.) + +The easiest way to make your CI faster is to do less work, and Nx is great at that. + +## Building Only What is Affected + +Nx knows what is affected by your PR, so it doesn't have to test/build/lint everything. Say the PR only touches `ng-lib9`. If you run `nx affected:dep-graph`, you will see something like this: + +![dependency-graph one library affected](/shared/ci-graph-one-affected.png) + +If you update `azure-pipelines.yml` to use `nx affected` instead of `nx run-many`: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx affected --target=test --base=origin/master' + } + + stage("Lint") { + sh 'yarn nx affected --target=lint --base=origin/master' + } + + stage("Build") { + sh 'yarn nx affected --target=build --base=origin/master --prod' + } + } + } +} +``` + +the CI time will go down from 45 minutes to 8 minutes. + +This is a good result. It helps to lower the average CI time, but doesn't help with the worst case scenario. Some PR are going to affect a large portion of the repo. + +![dependency-graph everything affected](/shared/ci-graph-everything-affected.png) + +You could make it faster by running the commands in parallel: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx affected --target=test --base=origin/master --parallel' + } + + stage("Lint") { + sh 'yarn nx affected --target=lint --base=origin/master --parallel' + } + + stage("Build") { + sh 'yarn nx affected --target=build --base=origin/master --prod --parallel' + } + } + } +} +``` + +This helps but it still has a ceiling. At some point, this won't be enough. A single agent is simply insufficent. You need to distribute CI across a grid of machines. + +## Distributed CI + +To distribute you need to split your job into multiple jobs. + +``` + + / lint1 +Prepare Distributed Tasks - lint2 + - lint3 + - test1 + .... + \ build3 + +``` + +### Distributed Setup + +```groovy +def distributedTasks = [:] + +stage("Building Distributed Tasks") { + jsTask { + checkout scm + sh 'yarn install' + + distributedTasks << distributed('test', 3) + distributedTasks << distributed('lint', 3) + distributedTasks << distributed('build', 3) + } +} + +stage("Run Distributed Tasks") { + parallel distributedTasks +} + +def jsTask(Closure cl) { + node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config', cl) + } + } +} + +def distributed(String target, int bins) { + def jobs = splitJobs(target, bins) + def tasks = [:] + + jobs.eachWithIndex { jobRun, i -> + def list = jobRun.join(',') + def title = "${target} - ${i}" + + tasks[title] = { + jsTask { + stage(title) { + checkout scm + sh 'yarn install' + sh "npx nx run-many --target=${target} --projects=${list} --parallel" + } + } + } + } + + return tasks +} + +def splitJobs(String target, int bins) { + def String baseSha = env.CHANGE_ID ? 'origin/master' : 'origin/master~1' + def String raw + raw = sh(script: "npx nx print-affected --base=${baseSha} --target=${target}", returnStdout: true) + def data = readJSON(text: raw) + + def tasks = data['tasks'].collect { it['target']['project'] } + + if (tasks.size() == 0) { + return tasks + } + + // this has to happen because Math.ceil is not allowed by jenkins sandbox (╯°□°）╯︵ ┻━┻ + def c = sh(script: "echo \$(( ${tasks.size()} / ${bins} ))", returnStdout: true).toInteger() + def split = tasks.collate(c) + + return split +} + +``` + +Let's step through it: + +To run jobs in parallel with jenkins, we need to construct a map of `string -> closure` where `closure` contains the code we want to be running +in parallel. The goal of the `distributed` function is to build a compatible map. It starts by figuring out what jobs need to be run, and +splitting them into bins via `splitJobs`. + +Looking at `splitJobs`, the following defines the base sha Nx uses to execute affected commands. + +```groovy + def String baseSha = env.CHANGE_ID ? 'origin/master' : 'origin/master~1' +``` + +Jenkins will only have a CHANGE_ID if it is a PR. + +If it is a PR, Nx sees what has changed compared to `origin/master`. If it's master, Nx sees what has changed compared to the previous commit (this can be made more robust by remembering the last successful master run, which can be done by labeling the commit). + +The following prints information about affected project that have the needed target. `print-affected` doesn't run any targets, just prints information about them. + +```groovy +def String raw +jsTask { raw = sh(script: "npx nx print-affected --base=${baseSha} --target=${target}", returnStdout: true) } +def data = readJSON(text: raw) +``` + +We split the jobs into bins with `collate`. + +Once we have our lists of jobs, we can go back to the `distributed` method. We loop over the list of split jobs for our target, +and construct the map that jenkins requires to parallelize our jobs. + +```groovy +def tasks = [:] + +jobs.eachWithIndex { jobRun, i -> +jsTask { echo 'loop' } + +def list = jobRun.join(',') +def title = "${target} - ${i}" + +tasks[title] = { + jsTask { + stage(title) { + sh "npx nx run-many --target=${target} --projects=${list} --parallel" + } + } +} +} +``` + +finally, we merge each map of target jobs into a big map, and pass that to `parallel`. + +```groovy +stage("Building Distributed Tasks") { + jsTask { + checkout scm + sh 'yarn install' + + distributedTasks << distributed('test', 3) + distributedTasks << distributed('lint', 3) + distributedTasks << distributed('build', 3) + } +} + +``` + +### Improvements + +With these changes, rebuild/retesting/relinting everything takes only 7 minutes. The average CI time is even faster. The best part of this is that you can add more agents to your pool when needed, so the worst-case scenario CI time will always be under 15 minutes regardless of how big the repo is. + +## Summary + +1. Rebuilding/retesting/relinting everyting on every code change doesn't scale. **In this example it takes 45 minutes.** +2. Nx lets you rebuild only what is affected, which drastically improves the average CI time, but it doesn't address the worst-case scenario. +3. Nx helps you run multiple targets in parallel on the same machine. +4. Nx provides `print-affected` and `run-many` which make implemented distributed CI simple. **In this example the time went down from 45 minutes to only 7** diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-nx-enterprise.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-nx-enterprise.md new file mode 100644 index 0000000000..483214ac36 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-nx-enterprise.md @@ -0,0 +1,198 @@ +# Using Nx at Enterprises + +Nx is a great tool for companies of all sizes. These days even small products have several microservies and several frontends (say desktop and mobile) which are often built by distributed teams. Being able to do this type of development holistically, using modern tools, is as important for a startup as it is for a well-established organization. + +Some things, however, are much more important for large companies: + +- Code organization & naming conventions +- Code ownership +- Enforcing best practices +- Developer workflow +- Deployment flexibility + +> Everything below are just recommendations. Every large organization has unique needs, so treat this document as a starting point not the definite list of what you must and must not do. + +## Code Organization & Naming Conventions + +### Apps and Libs + +- Apps configure dependency injection and wire up libraries. They should not contain any components, services, or business logic. +- Libs contain services, components, utilities, etc.. They have well-defined public API. + +A typical Nx workspace has many more libs than apps, so pay especially careful attention to the organization of the libs directory. + +### Scope (Where a library lives, who owns it) + +It's a good convention to put applications-specific libraries into the directory matching the application name. This provides enough organization for small to mid-size applications. + +```treeview +happynrwl/ +├── apps/ +│ ├── happynrwlapp/ +│ ├── happynrwlapp-e2e/ +│ ├── adminapp/ +│ └── adminapp-e2e/ +├── libs/ +│ ├── happynrwlapp/ +│ │ ├── feature-main/ +│ │ ├── ui-table/ +│ │ └── utils-testing/ +│ ├── adminapp/ +│ │ ├── feature-main/ +│ │ ├── feature-login/ +│ │ ├── ui/ +│ │ └── utils-testing/ +│ └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +For larger projects, it is a good idea to group libraries into application sections. + +```treeview +happynrwl/ +├── apps/ +├── libs/ +│ ├── happynrwlapp/ +│ │ ├── registration/ +│ │ │ ├── feature-main/ +│ │ │ ├── feature-login/ +│ │ │ ├── ui-form/ +│ │ │ └── utils-testing/ +│ │ ├── search/ +│ │ │ ├── feature-results/ +│ │ │ └── utils-testing/ +│ │ └── shared/ +│ │ └── ui/ +│ ├── adminapp/ +| └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Here we have: + +- `happynrwlapp/registration/feature-main`--a scoped library used in one place +- `happynrwlapp/shared/ui`--a shared library used in a single application +- `shared/ui`--a shared library used across applications + +**Portal** + +Many enterprise applications are portals: slim shells loading different modules at runtime. If this is what you are building, the following might be a better starting point: + +```treeview +happynrwl/ +├── apps/ +│ ├── happynrwlapp/ +│ ├── happynrwlapp-e2e/ +├── libs/ +│ ├── shell/ +│ │ └── feature-main +│ ├── registration/ +│ │ ├── feature-main/ +│ │ ├── feature-login/ +│ │ ├── ui-form/ +│ │ └── utils-testing/ +│ ├── search/ +│ │ ├── feature-results/ +│ │ └── utils-testing/ +│ └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +### Type (What is in the library) + +With Nx, we can partition our code into small libraries with well-defined public API. So we can categorize our libraries based on what they contain. + +**These are some common library types:** + +- Utility libraries contain utilities and services. +- Data-access can contain NgRx-related code. +- Component libraries should contain presentational components and directives. +- Feature libraries contain business logic, application screens, etc. + +This categorization is a good starting point, but other library types are quite common too (e.g., mock libraries). It's a good idea to establish naming conventions (e.g., `utilities-testing`, `components-buttons`). Having them helps developers explore the code and feel comfortable no matter where they are in the repository. + +### Managing Dependencies + +For a large organization it's crucial to establish how projects can depend on each other. For instance: + +- Libraries with a broader scope (e.g., `shared/ui`) should not depend on the libraries with narrower scope (e.g., `happynrwlapp/search/utils-testing`). +- Component libraries should only depend on other component libraries and utility libraries, but should not depend feature libraries. + +Nx provides a feature called tags that can be used to codify and statically-enforce these rules. Read more about tags [here](/shared/monorepo-tags). + +## Code Ownership + +It's crucial for a large company with multiple teams contributing to the same repository to establish clear code ownership. + +Since Nx allows us to group apps and libs in directories, those directories can become code-ownership boundaries. That's why the structure of an Nx workspace often reflects the structure of an organization. GitHub users can use the `CODEOWNERS` file for that. + +``` +/libs/happynrwlapp julie-happynrwlapp-lead +/apps/happynrwlapp julie-happynrwlapp-lead +/libs/shared/ui hank-the-ui-guy +/libs/shared/utils-testing julie,hank +``` + +## Enforcing Best Practices + +When we have 10 people working on an app in the same room, we can agree on best practices over lunch. We can also make sure the team follows them by reviewing each other's PRs. For a team of a hundred located in different cities, this no longer works. + +With Nx, we can help teams adopt best practices by using workspace schematics and workspace lint checks. + +### Workspace Schematics + +Schematics is a library used by Nx to do code generation. `nx g lib mylib` invokes the lib schematic from the default collection. Schematics are a great way to codify conventions and best practices. Unfortunately, creating a custom schematics collection is not very straightforward, so few do it. + +Nx simplifies it. With Nx, we can create custom schematics in the `tools/schematics` and invoke them without having to do compile, build, deploy anything. + +Read more about workspace schematics in the Workspace Schematics guide. + +### Workspace Lint Checks + +Custom lint checks is another great way to enforce best practices. We can create custom lint checks in the `tools/lint` directory and then register them in `tslint.json`or `.eslintrc.json`. + +## Developer Workflow + +Embracing the monorepo-style development often requires some changes to the development workflow. + +**Our CI should run the following checks:** + +- It checks that the changed code is formatted properly. (`nx format:check`) +- It runs lint checks for all the projects affected by a PR/commit. +- It runs unit tests for all the projects affected by a PR/commit. +- It runs e2e tests for all the apps affected by a PR/commit. +- It rebuilds all the apps affected by a PR/commit. + +Note `all the projects affected by a PR/commit`. This is very important. Monorepo-style development only works if we rebuild, retest, and relint only the projects that can be affected by our changes. If we instead retest everything, we will get the the following problems: + +- The performance of CI checks will degrade over time. The time it takes to run the CI checks should be proportional to the impact of the change, not the size of the repo. +- We will be affected by the code your change didn’t touch + +We should utilize `affected:*` commands to build and test projects. Read more about them [here](/shared/monorepo-affected). + +### Trunk-based development + +Monorepo-style development works best when used with trunk-based development. + +When using trunk-based development, we have a single main branch (say `master`) where every team submits their code. And +they do it as soon as possible. So if someone works on a large feature, they split it into a few small changes that can be integrated into master in a week. In other words, when using trunk-based development, teams can create branches, but they are short-lived and focus on a specific user story. + +One issue folks often raise in regards to trunk-based development is "things change under you while you are trying to create a release". This can definitely happen, especially when manual testing is involved. To mitigate we can create a release branch where we would cherry-pick commits from `master` to. With this, we can still frequently merge code into `master` and have our release isolated from changes made by other teams. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-tags.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-tags.md new file mode 100644 index 0000000000..526f0b53c2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/monorepo-tags.md @@ -0,0 +1,109 @@ +# Imposing Constraints on the Dependency Graph + +If you partition your code into well-defined cohesive units, even a small organization will end up with a dozen apps and dozens or hundreds of libs. If all of them can depend on each other freely, the chaos will ensue, and the workspace will become unmanageable. + +To help with that Nx uses code analyses to make sure projects can only depend on each other's well-defined public API. It also allows you to declaratively impose constraints on how projects can depend on each other. + +## Tags + +Nx comes with a generic mechanism for expressing constraints: tags. + +First, use `nx.json` to annotate your projects with tags. In this example, we will use three tags: `scope:client`. `scope:admin`, `scope:shared`. + +```json +{ + "npmScope": "myorg", + "implicitDependencies": { + "package.json": "*", + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "client": { + "tags": ["scope:client"], + "implicitDependencies": [] + }, + "client-e2e": { + "tags": ["scope:client"], + "implicitDependencies": ["client"] + }, + "admin": { + "tags": ["scope:admin"], + "implicitDependencies": [] + }, + "admin-e2e": { + "tags": ["scope:admin"], + "implicitDependencies": ["admin"] + }, + "client-feature-main": { + "tags": ["scope:client"], + "implicitDependencies": [] + }, + "admin-feature-permissions": { + "tags": ["scope:admin"], + "implicitDependencies": [] + }, + "components-shared": { + "tags": ["scope:shared"], + "implicitDependencies": [] + } + } +} +``` + +Next open the top-level `.eslintrc.json` or `tslint.json` to add the constraints. + +```json +{ + "nx-enforce-module-boundaries": [ + true, + { + "allow": [], + "depConstraints": [ + { + "sourceTag": "scope:shared", + "onlyDependOnLibsWithTags": ["scope:shared"] + }, + { + "sourceTag": "scope:admin", + "onlyDependOnLibsWithTags": ["scope:shared", "scope:admin"] + }, + { + "sourceTag": "scope:client", + "onlyDependOnLibsWithTags": ["scope:shared", "scope:client"] + } + ] + } + ] +} +``` + +With these constraints in place, `scope:client` projects can only depend on other `scope:client` projects or on `scope:shared` projects. And `scope:admin` projects can only depend on other `scope:admin` projects or on `scope:shared` projects. So `scope:client` and `scope:admin` cannot depend on each other. + +Projects without any tags cannot depend on any other projects. If you add the following, projects without any tags will be able to depend on any other project. + +```json +{ + "sourceTag": "*", + "onlyDependOnLibsWithTags": ["*"] +} +``` + +If you try to violate the constrains, you will get an error: + +``` +A project tagged with "scope:admin" can only depend on projects tagged with "scoped:shared" or "scope:admin". +``` + +### Exceptions + +The `"allow": []` are the list of imports that won't fail linting. + +- `"allow": ['@myorg/mylib/testing']` allows importing `'@myorg/mylib/testing'`. +- `"allow": ['@myorg/mylib/*']` allows importing `'@myorg/mylib/a'` but not `'@myorg/mylib/a/b'`. +- `"allow": ['@myorg/mylib/**']` allows importing `'@myorg/mylib/a'` and `'@myorg/mylib/a/b'`. +- `"allow": ['@myorg/**/testing']` allows importing `'@myorg/mylib/testing'` and `'@myorg/nested/lib/testing'`. + +## Multiple Dimensions + +The example above shows using a single dimension: `scope`. It's the most commonly used one. But you can find other dimensions useful. You can define which projects contain components, state management code, and features, so you, for instance, can disallow projects containing dumb UI components to depend on state management code. You can define which projects are experimental and which are stable, so stable applications cannot depend on experimental projects etc. You can define which projects have server-side code and which have client-side code to make sure your node app doesn't bundle in your frontend framework. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-logo.png new file mode 100644 index 0000000000..f1e2703531 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-plugin.md new file mode 100644 index 0000000000..091d39ce89 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/nest-plugin.md @@ -0,0 +1,199 @@ +# Nest Plugin + +![NestJS logo](/shared/nest-logo.png) + +Nest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers: + +- It has excellent TypeScript support. +- Its dependency injection system is similar to the one in Angular. +- It emphasises testability. +- Its configuration APIs are similar to Angular as well. + +Many conventions and best practices used in Angular applications can be also be used in Nest. + +## Installing the Nest Plugin + +Installing the Nest plugin to a workspace can be done with the following: + +```shell script +yarn add -D @nrwl/nest +``` + +```shell script +npm install -D @nrwl/nest +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/nest:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ +    └── nest-app/ +       ├── jest.config.js +       ├── src/ +       │   ├── app/ +       │   │   ├── app.controller.ts +       │   │   ├── app.controller.spec.ts +       │   │   ├── app.module.ts +       │   │   ├── app.service.ts +       │   │   └── app.service.spec.ts +       │   ├── assets/ +       │   ├── environments/ +       │   └── main.ts +       ├── tsconfig.app.json +       ├── tsconfig.json +       ├── tsconfig.spec.json +       └── tslint.json +``` + +The `main.ts` content should look similar to this: + +```typescript +import { NestFactory } from '@nestjs/core'; + +import { AppModule } from './app/app.module'; + +async function bootstrap() { + const app = await NestFactory.create(AppModule); + const globalPrefix = 'api'; + app.setGlobalPrefix(globalPrefix); + const port = process.env.port || 3333; + await app.listen(port, () => { + console.log('Listening at http://localhost:' + port + '/' + globalPrefix); + }); +} + +bootstrap(); +``` + +#### Application Proxies + +Generating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/nest:application --frontendProject my-angular-app +``` + +### Application commands + +When a Nest application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Nest application to be rebuilt automatically. +Nest applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nestjs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +##### Waiting for other builds + +Setting the `waitUntilTargets` option with an array of projects (with the following format: `"project:architect"`) will execute those commands before serving the Nest application. + +#### lint + +The lint command will run linting within the scope of the Nest app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Nest app. + +```shell script +nx test +``` + +## Libraries + +Nest libraries are a good way to separate features within your organization. To create a Nest library run the following command: + +```shell script +nx generate @nrwl/nest:library +``` + +Nest libraries can also be generated with an included controller, service or making the module global with their respective flags. + +```shell script +nx generate @nrwl/nest:library [--controller] [--service] [--global] + +``` + +#### Buildable libraries + +Libraries can also be enabled to be built separately from apps. To create a buildable library, add the `--buildable` flag to the generate command above. + +```shell script +nx generate @nrwl/nest:library --buildable +``` + +### Library commands + +When a Nest library is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### lint + +The lint command will run linting within the scope of the Nest library. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Nest library. + +```shell script +nx test +``` + +> Note: By default, Nest libraries are generated with Jest's test environment set to `node` + +#### build + +The build command will only be available if the library was generated with the `--buildable` flag. + +Buildable Nest libraries use TypeScript to compile the source. The tsconfig files that are generated with the library allow customization of the compiled output. + +```shell script +nx build +``` + +## Nest Schematics + +The Nest plugin for Nx extends the schematics provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--sourceRoot` flag should be used for all Nest schematics. + +> The `--sourceRoot` command should point to the source directory of a Nest library or application within an Nx workspace. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/next-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/next-plugin.md new file mode 100644 index 0000000000..e4fd1c38fc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/next-plugin.md @@ -0,0 +1,73 @@ +# Next.js Plugin + +The Nx Plugin for Next.js contains builders and schematics for managing Next.js applications and libraries within an Nx workspace. It provides: + +- Scaffolding for creating, building, serving, linting, and testing Next.js applications. +- Integration with building, serving, and exporting a Next.js application. +- Integration with React libraries within the workspace. + +## Installing the Next.js Plugin + +Installing the Next plugin to a workspace can be done with the following: + +```shell script +yarn add -D @nrwl/next +``` + +```shell script +npm install -D @nrwl/next +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/next:application +``` + +This creates the following app structure: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── pages/ +│   │   │   ├── index.css +│   │   │   └── index.tsx +│   │   ├── jest.conf.js +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── .eslintrc.json +│   └── myapp-e2e/ +│   │   ├── src/ +│   │   │   ├── integrations/ +│   │   │   │   └── app.spec.ts +│   │   │   ├── fixtures/ +│   │   │   ├── plugins/ +│   │   │   └── support/ +│   │   ├── cypress.json +│   │   ├── tsconfig.e2e.json +│   │   └── .eslintrc.json +├── libs/ +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── .eslintrc.json +``` + +## See Also + +- [Using Next.js](https://nextjs.org/docs/getting-started) + +## Builders + +- [build](/{{framework}}/plugins/next/builders/build) - Builds a Next.js application +- [dev-server](/{{framework}}/plugins/next/builders/dev-server) - Builds and serves a Next.js application +- [export](/{{framework}}/plugins/next/builders/package) - Export a Next.js app. The exported application is located at `dist/$outputPath/exported` + +## Schematics + +- [application](/{{framework}}/plugins/next/schematics/application) - Create an Next.js application diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/node-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/node-plugin.md new file mode 100644 index 0000000000..e57256327e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/node-plugin.md @@ -0,0 +1,153 @@ +# Node Plugin + +The Node Plugin contains schematics and builders to manage Node applications within an Nx workspace. + +## Installing the Node Plugin + +Installing the Node plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/node +``` + +```shell script +#npm +npm install -D @nrwl/node +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/node:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ + └── node-app/ +    ├── jest.config.js +    ├── src/ +    │   ├── app/ +    │   ├── assets/ +    │   ├── environments/ +    │   │   ├── environment.prod.ts +    │   │   └── environment.ts +    │   └── main.ts +    ├── tsconfig.app.json +    ├── tsconfig.json +    ├── tsconfig.spec.json +   └── tslint.json +``` + +From here files can be added within the `app` folder. +Make sure to import any files within the `main.ts` file so that they can be executed when the application is ran. + +#### Application Proxies + +Generating Node applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/node:application --frontendProject my-react-app +``` + +### Application commands + +When a Node application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Node application to be rebuilt automatically. +Node applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +#### lint + +The lint command will run linting within the scope of the Node app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Node app. + +```shell script +nx test +``` + +## Libraries + +Node libraries are a good way to separate features within your organization. To create a Node library run the following command: + +```shell script +nx generate @nrwl/node:library +``` + +#### Buildable libraries + +Libraries can also be enabled to be built separately from apps. To create a buildable library, add the `--buildable` flag to the generate command above. + +```shell script +nx generate @nrwl/node:library --buildable +``` + +### Library commands + +When a Node library is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### lint + +The lint command will run linting within the scope of the Node library. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Node library. + +```shell script +nx test +``` + +#### build + +The build command will only be available if the library was generated with the `--buildable` flag. + +Buildable Node libraries use TypeScript to compile the source. The tsconfig files that are generated with the library allow customization of the compiled output. + +```shell script +nx build +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-logo.png new file mode 100644 index 0000000000..11d0c0758f Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-screenshot.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-screenshot.png new file mode 100644 index 0000000000..0a444ee0d5 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-console-screenshot.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-plugin.md new file mode 100644 index 0000000000..3d45c48ebb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/nx-plugin.md @@ -0,0 +1,264 @@ +# Nx Plugins + +Nx plugins are npm packages that contain schematics and builders to extend a Nx workspace. Schematics are blueprints to create new files from templates, and builders execute those files. These plugins also update the `nx.json` when generating new libs or apps. + +> A list of plugins that is maintained by Nrwl is found in the [Nrwl/nx repo](https://github.com/nrwl/nx/tree/master/packages). \ +> A list of custom plugins created by the community is found in the [Community](/nx-community) section. + + + +## Generating a Plugin + +To get started with building a Nx Plugin, run the following command: + +```bash +npx create-nx-plugin my-org --pluginName my-plugin +``` + +This command creates a brand new workspace, and sets up a pre-configured plugin with the specified name. + +## Workspace Structure + +After executing the above command, the following tree structure is created: + +```treeview +my-org/ +├── e2e/ +│ └── my-plugin-e2e/ +│ ├── jest.config.js +│ ├── tests/ +│ │ └── my-plugin.test.ts +│ ├── tsconfig.json +│ └── tsconfig.spec.json +├── packages/ +│ └── my-plugin/ +│ ├── README.md +│ ├── builders.json +│ ├── collection.json +│ ├── jest.config.js +│ ├── package.json +│ ├── src/ +│ │ ├── builders/ +│ │ │ └── my-plugin/ +│ │ │ ├── builder.spec.ts +│ │ │ ├── builder.ts +│ │ │ ├── schema.d.ts +│ │ │ └── schema.json +│ │ ├── index.ts +│ │ └── schematics/ +│ │ └── my-plugin/ +│ │ ├── files/ +│ │ │ └── src/ +│ │ │ └── index.ts.template +│ │ ├── schema.d.ts +│ │ ├── schema.json +│ │ ├── schematic.spec.ts +│ │ └── schematic.ts +│ ├── tsconfig.json +│ ├── tsconfig.lib.json +│ └── tsconfig.spec.json +├── tools +│ ├── schematics/ +│ └── tsconfig.tools.json +├── jest.config.js +├── nx.json +├── package.json +├── tsconfig.json +├── workspace.json +└── yarn.lock +``` + +> If you do not want to create a new workspace, install the `@nrwl/nx-plugin` dependency in an already existing workspace with npm or yarn. Then run `nx g @nrwl/nx-plugin:plugin [pluginName]`. + +A new plugin is created with a default schematic, builder, and e2e app. + +## Schematic + +The generated schematic contains boilerplate that will do the following: + +- Normalize a schema (the options that the schematic accepts) +- Update the `workspace.json` (or `angular.json` if the plugin is used in a Angular CLI workspace) +- Add the plugin's project to the `nx.json` file +- Add files to the disk using templates + +To change the type of project the plugin generates, change the `projectType` const with the `ProjectType` enum. This ensures that generated projects with the plugin will go in to the correct workspace directory (`libs/` or `apps/`). + +```typescript +const projectType = ProjectType.Library; +// OR +// const projectType = ProjectType.Application; +``` + +### Schematic options + +The `schema.d.ts` file contains all the options that the schematic supports. By default, it includes `directory`, `tags`, and `name` as the options. If more options need to be added, please update this file and the `schema.json` file. + +> Note: The `schema.d.ts` file is used for type checking inside the implementation file. It should match the properties in `schema.json`. + +### Adding more schematics + +To add more schematics to the plugin, create a new folder that contains a implementation file, a `schema.json` file, and a `schema.d.ts` file. After, edit the `collection.json` file and add the new schematic there. + +```json +{ + "$schema": "../../node_modules/@angular-devkit/schematics/collection-schema.json", + "name": "my-plugin", + "version": "0.0.1", + "schematics": { + "myPlugin": { + "factory": "./src/schematics/my-plugin/schematic", + "schema": "./src/schematics/my-plugin/schema.json", + "description": "my-plugin schematic" + }, + // new schematic + "added-schematic": { + "factory": "./src/schematics/added-schematic/schematic", + "schema": "./src/schematics/added-schematic/schema.json", + "description": "added-schematic schematic" + } + } +} +``` + +For more information on how schematics work, see [angular.io/guide/schematics-authoring](https://angular.io/guide/schematics-authoring) + +### Schematic Testing + +The schematic spec file includes boilerplate to help get started with testing. This includes setting up a empty workspace, and the schematic test runner. + +Full E2Es are supported (and recommended) and will run everything on the file system like a user would. + +## Builder + +The default builder is set up to just emit a console log. Some examples of what a builder can do are: + +- Use the .NET core compiler (or something similar) +- Compile Stencil/Svelte/Vue components +- Deploy an app on a CDN +- Publish to NPM +- and many more! + +### Adding more builders + +Adding more builders to the plugin is exactly the same as adding more schematics. Create a new folder and add a implementation, `schema.json` and `schema.d.ts` files. Then edit the `builders.json` file in the root of the plugin project. + +```json +{ + "$schema": "../../node_modules/@angular-devkit/architect/src/builders-schema.json", + "builders": { + "build": { + "implementation": "./src/builders/my-plugin/builder", + "schema": "./src/builders/my-plugin/schema.json", + "description": "my-plugin builder" + }, + // new builder + "newBuilder": { + "implementation": "./src/builders/new-builder/builder", + "schema": "./src/builders/new-builder/schema.json", + "description": "new-builder builder" + } + } +} +``` + +> Note: to use builders in any target (inside the `workspace.json` or `angular.json`), use the following syntax `@my-org/my-plugin:newBuilder` + +For more information on how builders work, see [angular.io/guide/cli-builder](https://angular.io/guide/cli-builder) + +### Builder testing + +The builder spec file contains boilerplate to set up the `CoreSchemaRegistry`, `TestingArchitectHost` and adds the builder from a package.json. + +There are some additional comments to help with these tests. For more information about testing builders, see [angular.io/guide/cli-builder#testing-a-builder](https://angular.io/guide/cli-builder#testing-a-builder). + +Full E2Es are supported (and recommended) and will run everything on the file system like a user would. + +## Testing your plugin + +One of the biggest benefits that the Nx Plugin package provides is support for E2E testing. + +When the E2E app runs, a temporary E2E directory is created in the root of the workspace. This directory is a blank Nx workspace, and will have the plugin's built package installed locally. + +### E2E Testing file + +When the plugin is generated, a test file is created in the `my-plugin-e2e` app. Inside this test file, there are already tests for making sure that the builder ran, checking if directories are created with the `--directory` option, and checking if tags are added to `nx.json`. + +We'll go over a few parts of a test file below: + +```typescript +it('should create my-plugin', async (done) => { + const plugin = uniq('my-plugin'); + ensureNxProject('@my-org/my-plugin', 'dist/packages/my-plugin'); + await runNxCommandAsync(`generate @my-org/my-plugin:myPlugin ${plugin}`); + + const result = await runNxCommandAsync(`build ${plugin}`); + expect(result.stdout).toContain('Builder ran'); + + done(); +}); +``` + +- The `uniq` function creates a random name with the prefix and a random number. +- The `ensureNxProject` is the function that will create the temporary directory. It takes two arguments, the plugin package name and the dist directory of when it's built. +- The `runNxCommandAsync` will execute a `nx` command in the E2E directory. + +There are additional functions that the `@nrwl/nx-plugin/testing` package exports. Most of them are file utilities to manipulate and read files in the E2E directory. + +## Including Assets + +Sometimes you might want to include some assets with the plugin. This might be a image or some additional binaries. + +To make sure that assets are copied to the dist folder, open the `workspace.json` (or `angular.json`) file, and find the plugin's project. Inside the `build` property, add additional assets. By default, all `.md` files in the root, all non-ts files in folders, and the `collection.json` and `builders.json` files are included. + +```json +"build": { + "builder": "@nrwl/node:package", + "options": { + // shortened... + "assets": [ + "packages/my-plugin/*.md", + { + "input": "./packages/my-plugin/src", + "glob": "**/*.!(ts)", + "output": "./src" + }, + { + "input": "./packages/my-plugin", + "glob": "collection.json", + "output": "." + }, + { + "input": "./packages/my-plugin", + "glob": "builders.json", + "output": "." + } + ] + } +} +``` + +## Publishing your Nx Plugin + +To publish your plugin follow these steps: + +1. Build your plugin with the command `nx run my-plugin:build` +1. `npm publish ./dist/package/my-plugin` and follow the prompts from npm. +1. That's it! + +> Note: currently you will have to modify the `package.json` version by yourself or with a tool. + +After that, you can then install your plugin like any other npm package, +`npm i -D @my-org/my-plugin` or `yarn add -D @my-org/my-plugin`. + +### Listing your Nx Plugin + +Nx provides a utility (`nx list`) that lists both core and community plugins. To submit your plugin, please follow the steps below: + +- Fork the [Nx repo](https://github.com/nrwl/nx/fork) (if you haven't already) +- Update the [`community/approved-plugins.json` file](https://github.com/nrwl/nx/blob/master/community/approved-plugins.json) with a new entry for your plugin that includes name, url and description +- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]` +- push your changes, and run `yarn submit-plugin` + +> The `yarn submit-plugin` command automatically opens the Github pull request process with the correct template. + +We will then verify the plugin, offer suggestions or merge the pull request! diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/plugins-overview.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/plugins-overview.md new file mode 100644 index 0000000000..3ea5f1fff7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/plugins-overview.md @@ -0,0 +1,44 @@ +# Plugins + +Nx plugins are npm packages that contain schematics and builders to extend a Nx workspace. Schematics are blueprints to create or modify code, and builders perform actions on the code. + +## nx list + +Use the `nx list` command to see installed and available plugins. Both Nrwl maintained (`@nrwl/something`) and community plugins are listed. + +```bash +❯ nx list + +> NX Installed plugins: + + @nrwl/angular (builders,schematics) + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/linter (builders) + @nrwl/nest (schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-cloud (schematics) + @nrwl/workspace (builders,schematics) + + +> NX Also available: + + @nrwl/express (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/react (builders,schematics) + @nrwl/storybook (builders,schematics) + @nrwl/web (builders,schematics) + + +> NX Community plugins: + + @nxtend/ionic-react - An Nx plugin for developing Ionic React applications and libraries + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + @offeringsolutions/nx-karma-to-jest - Nx plugin for replacing karma with jest in an Nx workspace + @flowaccount/nx-serverless - Nx plugin for node/angular-universal schematics and deployment builders in an Nx workspace + @dev-thought/nx-deploy-it - Nx plugin to deploy applications on your favorite cloud provider +``` + +## See Also + +[Nx Community Plugins](/nx-community) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/prettier-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/prettier-logo.png new file mode 100644 index 0000000000..59bb947f29 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/prettier-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/react-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/react-plugin.md new file mode 100644 index 0000000000..3d45b88a7e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/react-plugin.md @@ -0,0 +1,90 @@ +# Nx Plugin for React + +The Nx Plugin for React contains schematics for managing React applications and libraries within an Nx workspace. It provides: + +- Integration with libraries such as Jest, Cypress, and Storybook. +- Scaffolding for state management with Redux Toolkit libraries. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the React plugin + +Adding the React plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/react +``` + +```shell script +#npm +npm install -D @nrwl/react +``` + +> Note: You can create a new workspace that has React set up by doing `npx create-nx-workspace@latest --preset=react` + +The file structure for a React application looks like: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.tsx +│   │   │   ├── polyfills.ts +│   │   │   └── styles.css +│   │   ├── browserslist +│   │   ├── jest.config.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   └── tsconfig.spec.json +│   └── myapp-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +## See Also + +- [Using Cypress](/{{framework}}/plugins/cypress/overview) +- [Using Jest](/{{framework}}/plugins/jest/overview) +- [Using Storybook](/{{framework}}/plugins/storybook/overview) + +## Builders + +React applications are built using the builders from the `@nrwl/web` plugin. + +- [build](/{{framework}}/plugins/web/builders/build) - Builds a web components application +- [dev-server](/{{framework}}/plugins/web/builders/package) - Builds and serves a web application +- [package](/{{framework}}/plugins/web/builders/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Schematics + +- [application](/{{framework}}/plugins/react/schematics/application) - Create an React application +- [component](/{{framework}}/plugins/react/schematics/component) - Create an React library +- [library](/{{framework}}/plugins/react/schematics/library) - Create an React library +- [redux](/{{framework}}/plugins/react/schematics/redux) - Generate a Redux slice for a project +- [storybook-configuration](/{{framework}}/plugins/react/schematics/storybook-configuration) - Set up Storybook for a react library diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/refresh-light.svg b/nx-dev/data-access-documents/src/data/10.4.13/shared/refresh-light.svg new file mode 100644 index 0000000000..e034574819 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/refresh-light.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/running-custom-commands.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/running-custom-commands.md new file mode 100644 index 0000000000..4ea8f7ce32 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/running-custom-commands.md @@ -0,0 +1,61 @@ +# Running Custom Commands + +This recipe will show how to run any terminal command within the nx build-chain. + +## Steps + +##### 1. Define the terminal command to be run + +The command we want to run for each project is: + +```bash +make hello +``` + +With this `Makefile` in the root of the project: + +```shell script +hello: + echo "Hello, world!" +``` + +##### 2. Update `workspace.json` + +For each project for which you want to enable `make`, add a target in `workspace.json`: + +```json +// ... +"my-app": { + "architect": { + "make": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "make hello" + } + ] + } + } + // ... + } +} +``` + +For more information, see the [run-commands api doc](/{{framework}}/plugins/workspace/builders/run-commands). + +##### 3. Trigger the builder from the terminal + +To run the builder for a single project: + +```bash +nx run my-app:make +``` + +To run the builder for all affected projects: + +```bash +nx affected --target=make +``` + +For more information, see the [nx affected](/{{framework}}/cli/affected). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/storybook-logo.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/storybook-logo.png new file mode 100644 index 0000000000..9201193134 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/storybook-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-builders.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-builders.md new file mode 100644 index 0000000000..8d2aa069e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-builders.md @@ -0,0 +1,221 @@ +# Creating Builders in Your Nx Workspace + +Creating builders for your workspace is a way to standardize scripts that you may run during your development/building/deploying tasks to enable Nx's `affected` command and caching capabilities. + +This guide will show you how to create, run, and customize builders within your Nx workspace. In the examples, we'll use the trivial use-case of an `echo` command. + +## Creating a Builder + +Your builder should be created within the `tools` directory of your Nx workspace like so: + +```treeview +happynrwl/ +├── apps/ +├── libs/ +├── tools/ +│ └── builders/ +│ └── echo/ +│ ├── builder.json +│ ├── impl.ts +│ ├── package.json +│ └── schema.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +### schema.json + +This file will describe the options being sent to the builder (very similar to the `schema.json` file of schematics). + +```json +{ + "$schema": "http://json-schema.org/schema", + "type": "object", + "properties": { + "textToEcho": { + "type": "string", + "description": "Text To Echo" + } + } +} +``` + +This example describes a single option for the builder that is a `string` called 'textToEcho'. When using this builder, we'll specify a 'textToEcho' property inside the options. + +In our `impl.ts` file, we're creating an `Options` interface that matches the json object being described here. + +### impl.ts + +The `impl.ts` contains the actual code for your builder. Your builder should use the `createBuilder` function of the `@angular-devkit/architect` package to create a builder that can be run via the Nx CLI tools. + +```ts +import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; +import * as childProcess from 'child_process'; +import { Observable } from 'rxjs'; +import { json } from '@angular-devkit/core'; + +interface Options extends json.JsonObject { + textToEcho: string; +} + +export default createBuilder((_options: Options, context) => { + context.logger.info(`Executing "echo"...`); + context.logger.info(`Options: ${JSON.stringify(_options, null, 2)}`); + const child = childProcess.spawn('echo', [_options.textToEcho]); + return new Observable((observer) => { + child.stdout.on('data', (data) => { + context.logger.info(data.toString()); + }); + child.stderr.on('data', (data) => { + context.logger.error(data.toString()); + }); + child.on('close', (code) => { + context.logger.info(`Done.`); + observer.next({ success: code === 0 }); + observer.complete(); + }); + }); +}); +``` + +See the [official Angular documentation on builders](https://angular.io/guide/cli-builder) for more clarification on creating builders. + +Also note that [Node’s `childProcess`](https://nodejs.org/api/child_process.html) is likely to be used in most cases. + +Part of the power of the architect API is the ability to compose builders via existing build targets. This way you can combine other builders from your workspace into one which could be helpful when the process you’re scripting is a combination of other existing builders provided by the CLI or other custom-builders in your workspace. + +Here's an example of this (from a hypothetical project), that will serve an api (project name: "api") in watch mode, then serve a frontend app (project name: "web-client") in watch mode: + +```ts +import { + BuilderContext, + BuilderOutput, + createBuilder, + scheduleTargetAndForget, + targetFromTargetString, +} from '@angular-devkit/architect'; +import { concat } from 'rxjs'; +import { concatMap, map } from 'rxjs/operators'; +interface Options extends json.JsonObject {} + +export default createBuilder((_options: Options, context: BuilderContext) => { + return concat( + scheduleTargetAndForget( + context, + targetFromTargetString('api:serve'), + { watch: true } + ), + scheduleTargetAndForget( + context, + targetFromTargetString('web-client:serve'), + { watch: true } + ) + ).pipe( + map(([apiBuilderContext, webClientBuilderContext]) => + ({ success: apiBuilderContext.success && webClientBuilderContext.success}) + ) + ); +``` + +For other ideas on how to create your own builders, you can always check out Nx's own open-source builders as well! + +(e.g. our [cypress builder](https://github.com/nrwl/nx/blob/master/packages/cypress/src/builders/cypress/cypress.impl.ts) + +### builder.json + +The `builder.json` file provides the description of your builder to the CLI. + +```json +{ + "builders": { + "echo": { + "implementation": "./impl", + "schema": "./schema.json", + "description": "Runs `echo` (to test builders out)." + } + } +} +``` + +Note that this `builder.json` file is naming our builder 'echo' for the CLI's purposes, and maping that name to the given implemetation file and schema. + +### package.json + +This is all that’s required from the `package.json` file: + +```json +{ + "builders": "./builder.json" +} +``` + +## Compiling and Running your Builder + +After your files are created, you can compile your builder with `tsc` (which should be available as long as you've installed Typescript globally: `npm i -g typescript`): + +```sh +tsc tools/builders/echo/impl +``` + +This will create the `impl.js` file in your file directory, which will serve as the artifact used by the CLI. + +Our last step is to add this builder to a given project’s `architect` object in your project's `workspace.json` or `angular.json` file. The example below adds this builder to a project named 'platform': + +```json +{ + //... + "projects": { + "platform": { + //... + "architect": { + "build": { + // ... + }, + "serve": { + // ... + }, + "lint": { + // ,,, + }, + "echo": { + "builder": "./tools/builders/echo:echo", + "options": { + "textToEcho": "Hello World" + } + } + } + } + } +} +``` + +Note that the format of the `builder` string here is: `${Path to directory containing the builder's package.json}:${builder name}`. + +Finally, we may run our builder via the CLI as follows: + +```sh +nx run platform:echo +``` + +To which we'll see the console output: + +```sh +> ng run platform:echo +Executing "echo"... +Hello World + +Done. +``` + +## Debugging Builders + +As part of Nx's computation cache process, Nx forks the node process, which can make it difficult to debug a builder command. Follow these steps to debug a builder: + +1. Make sure VSCode's `debug.node.autoAttach` setting is set to `On`. +2. Find the builder code and set a breakpoint. +3. Use node in debug to execute your builder command, replacing `nx` with the internal `tao` script. + +```bash +node --inspect-brk node_modules/.bin/tao build best-app +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-schematics.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-schematics.md new file mode 100644 index 0000000000..36a8e3fdd9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/tools-workspace-schematics.md @@ -0,0 +1,308 @@ +# Workspace Schematics + +Workspace schematics 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, schematics help you standardize these tasks in a consistent, and predictable manner. Nx provides tooling around creating, and running custom schematics from within your workspace. This guide shows you how to create, run, and customize workspace schematics within your Nx workspace. + +## Creating a workspace schematic + +Use the Nx CLI to generate the initial files needed for your workspace schematic. + +```sh +nx generate @nrwl/workspace:workspace-schematic my-schematic +``` + +After the command is finished, the workspace schematic is created under the `tools/schematics` folder. + +```treeview +happynrwl/ +├── apps/ +├── libs/ +├── tools/ +│ ├── schematics +│ | └── my-schematic/ +│ | | ├── index.ts +│ | | └── schema.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +The `index.ts` provides an entry point to the schematic. The file contains the factory function for the schematic to return a Rule. A rule is an operation that is performed against your filesystem. +The `schema.json` provides a description of the schematic, available options, validation information, and default values. + +The initial schematic entry point contains a rule to generate a library. + +```ts +import { chain, externalSchematic, Rule } from '@angular-devkit/schematics'; + +export default function (schema: any): Rule { + return chain([ + externalSchematic('@nrwl/workspace', 'lib', { + name: schema.name, + }), + ]); +} +``` + +The `chain` function takes a an array of rules and combines them into a single rule. You use this function to perform multiple operations against your workspace in a single schematic. The `externalSchematic` function allows you to call schematics provided from by an installed npm package. + +In the schema.json file for your schematic, the `name` is provided as a default option. + +```json +{ + "$schema": "http://json-schema.org/schema", + "id": "my-schematic", + "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 schematic. The first argument passed to this schematic is used as the `name` property. + +## Running a workspace schematic + +To run a schematic, invoke the `nx workspace-schematic` command with the name of the schematic. + +```sh +nx workspace-schematic my-schematic mylib +``` + +## Creating custom rules + +Schematics provide an API for managing files within your workspace. You can use schematics to do things such as create, update, move, and delete files. Files with static or dynamic content can also be created. + +The schematic 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/ +│ ├── schematics +│ | └── my-schematic/ +│ | | └── files +│ | | └── NOTES.md +│ | | ├── index.ts +│ | | └── schema.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Next, update the `index.ts` file for the schematic, and create different rules for generating a library, and generating the new files. Both rules have access to the available options provided for the schematic. + +```ts +import { + apply, + chain, + mergeWith, + move, + Rule, + SchematicContext, + Tree, + url, + externalSchematic, +} from '@angular-devkit/schematics'; +import { getProjectConfig } from '@nrwl/workspace'; + +function generateLibrary(schema: any): Rule { + return externalSchematic('@nrwl/workspace', 'lib', { + name: schema.name, + }); +} + +function generateFiles(schema: any): Rule { + return (tree: Tree, context: SchematicContext) => { + context.logger.info('adding NOTES.md to lib'); + + const templateSource = apply(url('./files'), [ + move(getProjectConfig(tree, schema.name).root), + ]); + + return chain([mergeWith(templateSource)])(tree, context); + }; +} + +export default function (schema: any): Rule { + return (tree: Tree, context: SchematicContext) => { + return chain([generateLibrary(schema), generateFiles(schema)])( + tree, + context + ); + }; +} +``` + +The exported function calls the two rules, first creating the library, then creating the additional files in the new library's folder. + +Next, run the schematic: + +> Use the `-d` or `--dry-run` flag to see your changes without applying them. + +```sh +nx workspace-schematic my-schematic mylib +``` + +The following information will be displayed. + +```sh +> NX Executing your local schematic: my-schematic + +CREATE libs/mylib/tslint.json (48 bytes) +CREATE libs/mylib/README.md (164 bytes) +CREATE libs/mylib/tsconfig.json (123 bytes) +CREATE libs/mylib/tsconfig.lib.json (172 bytes) +CREATE libs/mylib/src/index.ts (29 bytes) +CREATE libs/mylib/src/lib/mylib.ts (0 bytes) +CREATE libs/mylib/tsconfig.spec.json (273 bytes) +CREATE libs/mylib/jest.config.js (234 bytes) +CREATE libs/mylib/NOTES.md (15 bytes) +UPDATE tsconfig.json (582 bytes) +UPDATE angular.json (4751 bytes) +UPDATE nx.json (438 bytes) +UPDATE package.json (1959 bytes) +``` + +## Customizing schematic options + +### Adding a TypeScript schema + +To create a TypeScript schema to use in your schematic 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. + +```ts +export interface SchematicOptions { + name: string; + type?: string; +} +``` + +Import the TypeScript schema into your schematic file and replace the any in your schematic function with the interface. + +```ts +import { chain, externalSchematic, Rule } from '@angular-devkit/schematics'; +import { SchematicOptions } from './schema'; + +export default function (schema: SchematicOptions): Rule { + return chain([ + externalSchematic('@nrwl/workspace', 'lib', { + name: `${schema.name}-${schema.type || ''}`, + unitTestRunner: 'none', + }), + ]); +} +``` + +### Adding static options + +Static options for a schematic 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-schematic", + "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 schematic 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 an `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-schematic", + "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 schematic without providing a value for the type will prompt the user to make a selection. + +## Debugging Workspace schematics + +### With Visual Studio Code + +First of all make sure to enable the `debug.node.autoAttach` option. You can set it either in your workspace settings file inside `.vscode/settings.json` or your global `settings.json`. Simply add: + +```json +{ + "debug.node.autoAttach": "on" +} +``` + +Alternatively press Cmd+P (or Ctrl+P) to open VSCode's command palette and type "Debug: Toggle Auto Attach". + +Once you've activated the `autoAttach` option, set a breakpoint in VSCode and execute your schematic with the `--inspect-brk` flag: + +```sh +node --inspect-brk ./node_modules/nx/bin/nx.js workspace-schematic my-schematic mylib --dry-run +``` + +You may want to use the `--dry-run` flag to not actually apply the changes to the file system. + +![](/shared/vscode-schematics-debug.png) + +## Workspace schematic utilities + +The `@nrwl/workspace` 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/data-access-documents/src/data/10.4.13/shared/update.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/update.md new file mode 100644 index 0000000000..702770be2f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/update.md @@ -0,0 +1,77 @@ +# Updating Nx + +Nx provides migrations which help you stay up to date with the latest version of Nx. + +Not only do we migrate the version of Nx, but we also update the versions of dependencies which we install such as jest and cypress. + +We recommend waiting for Nx to update these dependencies for you as we verify that these versions work together. + +## How to Migrate + +### Generate migrations.json + +All you have to do to update Nx to the latest version is run the following: + +```bash +nx migrate @nrwl/workspace +nx migrate @nrwl/workspace@version # you can also specify version +``` + +This will fetch the specified version of `@nrwl/workspace`, analyze the dependencies and fetch all the dependent packages. The process will keep going until the whole tree of dependencies is resolved. This will result in: + +- `package.json` being updated +- `migrations.json` being generated + +At this point, no packages have been installed, and no other files have been touched. + +Now, you can inspect `package.json` to see if the changes make sense and install the packages by running `npm install` or `yarn`. + +### Run Migrations + +`migrations.json` contains the transformations that must run to prepare the workspace to the newly installed versions of packages. To run all the migrations, invoke: + +```bash +nx migrate --run-migrations=migrations.json +``` + +For small projects, running all the migrations at once often succeeds without any issues. + +For large projects, more flexibility is often needed: + +- You may have to skip a migration. +- You may want to run one migration at a time to address minor issues. +- You may want to reorder migrations. +- You may want to run the same migration multiple time if the process takes a long time and you had to rebase. + +Since you can run `nx migrate --run-migrations=migrations.json` as many times as you want, you can achieve all of that by commenting out and reordering items in `migrations.json`. + +The migrate process can take a long time, sometimes a day, so it can be useful to commit the migrations file. + +### Overriding versions + +Sometimes, you may want to use a different version of a package than what Nx recommends. You can do it as follows: + +```bash +nx migrate @nrwl/workspace --to="jest@22.0.0,cypress:3.4.0" +``` + +By default, Nx uses currently installed packages to calculate what migrations need to run. You can override them like this: + +```bash +nx migrate @nrwl/workspace --to="@nrwl/jest@8.0.0" +``` + +## Reverting a failed update + +Updates are best done on a clean git history so that it can be easily reversed if something fails. +We try our best to make sure migrations do not fail but if one does, **please report it** on [Github](https://www.github.com/nrwl/nx/issues/new/). +If an update fails for any reason, you can revert it as you do any other set of changes: + +```bash +git reset --hard # Reset any changes +git clean -fd # Delete newly added files and directories +``` + +## Updating Other Dependencies + +Nx does not handle updating the dependencies that Nx did not add. Please refer to those projects for the best updating strategy. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/using-builders.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/using-builders.md new file mode 100644 index 0000000000..b5cb842a23 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/using-builders.md @@ -0,0 +1,91 @@ +# Using Builders + +Builders perform actions on your code. This can include building, linting, testing, serving and many other actions. + +There are two main differences between a builder and a shell script or an npm script: + +1. Builders encourage a consistent methodology for performing similar actions on unrelated projects. i.e. A developer switching between teams can be confident that `nx build project2` will build `project2` with the default settings, just like `nx build project1` built `project1`. +2. Nx can leverage this consistency to perform the same builder command across multiple projects. i.e. `nx affected --target==test` will run the `test` builder command on every project that is affected by the current code change. + +## Builder Command Definitions + +The builder commands that are available for each project are defined and configured in the `/workspace.json` file. + +```json +{ + "projects": { + "cart": { + "root": "apps/cart", + "sourceRoot": "apps/cart/src", + "projectType": "application", + "schematics": {}, + "architect": { + "build": { + "builder": "@nrwl/web:build", + "options": { + "outputPath": "dist/apps/cart", + ... + }, + "configurations": { + "production": { + "sourceMap": false, + ... + } + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + ... + } + } + } + } + } +} +``` + +Each project has its builder commands defined in the `architect` property. In this snippet, `cart` has two builder commands defined - `build` and `test`. + +**Note:** `build` and `test` can be any strings you choose. For the sake of consistency, we make `test` run unit tests for every project and `build` produce compiled code for the projects which can be built. + +Each builder command definition has a `builder` property and, optionally, an `options` and a `configurations` property. + +- `builder` is a string of the from `[package name]:[builder name]`. For the `build` builder, the package name is `@nrwl/web` and the builder name is `build`. +- `options` is an object that contains any configuration defaults for the builder. These options vary from builder to builder. +- `configurations` allows you to create presets of options for different scenarios. All the configurations start with the properties defined in `options` as a baseline and then overwrite those options. In the example, there is a `production` configuration that overrides the default options to set `sourceMap` to `false`. + +## Executing Builder Commands + +The [`nx run`](/{{framework}}/cli/run) cli command (or the shorthand versions) can be used to execute builder commands. + +```bash +nx run [project]:[command] +nx run cart:build +``` + +As long as your command name doesn't conflict with an existing nx cli command, you can use this short hand: + +```bash +nx [command] [project] +nx build cart +``` + +You can also use a specific configuration preset like this: + +```bash +nx [command] [project] --configuration=[configuration] +nx build cart --configuration=production +``` + +Or you can overwrite individual builder options like this: + +```bash +nx [command] [project] --[optionNameInCamelCase]=[value] +nx build cart --outputPath=some/other/path +``` + +## See Also + +- [`nx affected`](/{{framework}}/cli/affected) +- [`nx run-many`](/{{framework}}/cli/run-many) diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/using-schematics.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/using-schematics.md new file mode 100644 index 0000000000..cbef5bb928 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/using-schematics.md @@ -0,0 +1,30 @@ +# Using Schematics + +## Overview + +Schematics 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, schematics help you standardize these tasks in a consistent, and predictable manner. + +Schematics are developed by the Angular Team at Google as part of the Angular DevKit, but are provided independently of the Angular framework. The DevKit packages are provided under the [@angular-devkit](https://npmjs.com/~angular-devkit) scope on npm. Nx provides additional tooling around creating, and running custom schematics from within your workspace. + +To read more about the concepts of Schematics, and building an example schematic, see the [Schematics Authoring Guide](https://angular.io/guide/schematics-authoring). + +The [Workspace Schematics](/{{framework}}/workspace/schematics/workspace-schematics) guide shows you how to create, run, and customize workspace schematics within your Nx workspace. + +## Types of Schematics + +There are three main types of schematics: + +1. **Plugin Schematics** are available when an Nx plugin has been installed in your workspace. +2. **Workspace Schematics** are schematics that you can create for your own workspace. [Workspace schematics](/{{framework}}/workspace/schematics/workspace-schematics) allow you to codify the processes that are unique to your own organization. +3. **Update Schematics** are invoked by Nx plugins when you [update Nx](/{{framework}}/workspace/update) to keep your config files in sync with the latest versions of third party tools. + +## Invoking Plugin Schematics + +Schematics allow you to create or modify your codebase in a simple and repeatable way. Schematics are invoked using the [`nx generate`](/{{framework}}/cli/generate) command. + +```bash +nx generate [plugin]:[schematic-name] [options] +nx generate @nrwl/react:component mycmp --project=myapp +``` + +It is important to have a clean git working directory before invoking a schematic so that you can easily revert changes and re-invoke the schematic with different inputs. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/vscode-schematics-debug.png b/nx-dev/data-access-documents/src/data/10.4.13/shared/vscode-schematics-debug.png new file mode 100644 index 0000000000..57efd4b6c1 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/10.4.13/shared/vscode-schematics-debug.png differ diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/web-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/web-plugin.md new file mode 100644 index 0000000000..fe698f59aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/web-plugin.md @@ -0,0 +1,86 @@ +# Nx Plugin for Web + +The Nx Plugin for Web Components contains schematics for managing Web Component applications and libraries within an Nx workspace. It provides: + +- Integration with libraries such as Jest, Cypress, and Storybook. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the Web plugin + +Adding the Web plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/web +``` + +```shell script +#npm +npm install -D @nrwl/web +``` + +> Note: You can create a new workspace that has Web Components set up by doing `npx create-nx-workspace@latest --preset=web-components` + +The file structure for a Web Components application looks like: + +```treeview +myorg/ +├── apps/ +│ ├── todos/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ └── styles.css +│ │ ├── browserslist +│ │ ├── jest.config.js +│ │ ├── tsconfig.app.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 +│ ├── tsconfig.e2e.json +│ └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +## See Also + +- [Using Cypress](/{{framework}}/plugins/cypress/overview) +- [Using Jest](/{{framework}}/plugins/cypress/overview) + +## Builders + +- [build](/{{framework}}/plugins/web/builders/build) - Builds a web components application +- [dev-server](/{{framework}}/plugins/web/builders/package) - Builds and serves a web application +- [package](/{{framework}}/plugins/web/builders/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Schematics + +- [application](/{{framework}}/plugins/web/schematics/application) - Create an Web Components application +- [component](/{{framework}}/plugins/web/schematics/component) - Create an Web Components library +- [library](/{{framework}}/plugins/web/schematics/library) - Create an Web Components library +- [redux](/{{framework}}/plugins/web/schematics/redux) - Generate a Redux slice for a project +- [storybook-configuration](/{{framework}}/plugins/web/schematics/storybook-configuration) - Set up Storybook for a react library diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-overview.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-overview.md new file mode 100644 index 0000000000..bb9ec7c2f4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-overview.md @@ -0,0 +1,50 @@ +# Nx Workspace + +## Files + +Every Nx workspace has a file structure like this: + +```treeview +myorg/ +├── apps/ +├── libs/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Nx makes it easy to split up your code into separate projects. Projects come in two varieties - applications and libraries. + +`/apps/` contains the application projects. These are 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 different 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 builders or workspace schematics. + +`/workspace.json` defines each project in your workspace and the builder commands that can be run on those projects. + +`/nx.json` adds extra information about projects, including manually defined dependencies and tags that can be used to restrict the ways projects are allowed to depend on each other. + +`/tsconfig.json` sets up the global typescript settings and creates aliases for each library to aid when creating typescript imports. + +## Configuration + +Many of the tools that Nx provides as plugins have a global configuration file that can be found at the root of workspace and a project-specific configuration file found at the root of each project that overrides the global settings for that project. + +For instance, `libA` has a `tsconfig.json` file that extends the global `tsconfig.json` file: + +```treeview +myorg/ +├── apps/ +├── libs/ +│ └── libA/ +│ ├── src/ +│ └── tsconfig.json +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-plugin.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-plugin.md new file mode 100644 index 0000000000..3529e62980 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace-plugin.md @@ -0,0 +1,14 @@ +# Workspace Plugin + +The workspace plugin contains builders and schematics that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it. + +## Schematics + +- [library](/angular/plugins/workspace/schematics/library) - Create a plain typescript library +- [move](/angular/plugins/workspace/schematics/move) - Move a project to another directory and update all references +- [remove](/angular/plugins/workspace/schematics/remove) - Remove a project from the workspace +- [workspace-schematic](/angular/plugins/workspace/schematics/workspace-schematic) - Scaffold a custom schematic for use within your workspace + +## Builders + +- [run-commands](/angular/plugins/workspace/builders/run-commands) - Execute an arbitrary command line script diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/buildable-and-publishable-libraries.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/buildable-and-publishable-libraries.md new file mode 100644 index 0000000000..f149f2eac7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/buildable-and-publishable-libraries.md @@ -0,0 +1,34 @@ +# Publishable and Buildable Nx Libraries + +The `--buildable` and `--publishable` options are available on the Nx library generation schematics for the following plugins: + +- Angular +- React +- NestJs +- Node + +This document will look to explain the motivations for why you would use either the `--buildable` or `--publishable` option, as well as the mechanics of how they adjust the result when you add them to your schematic. + +## Publishable libraries + +You might use the `--publishable` option when generating a new Nx library if your intention is to distribute it outside the monorepo. + +One typical scenario for this may be that you use Nx to develop your organizations UI design system component library (maybe using its [Storybook integration](https://nx.dev/latest/plugins/storybook/overview)), which should be available also to your organizations’ apps that are not hosted within the same monorepo. + +A normal Nx library - let’s call it "workspace library" - is not made for building or publishing. Rather it only includes common lint and test targets in its `angular.json` or `workspace.json`. These libraries are directly referenced from one of the monorepo’s applications and built together with them. + +Keep in mind that the `--publishable` flag does not enable automatic publishing. Rather it adds to your Nx workspace library a builder target that **compiles** and **bundles** your app. The resulting artifact will be ready to be published to some registry (e.g. [npm](https://npmjs.com/)). By having that builder, you can invoke the build via a command like: `nx build mylib` (where "mylib" is the name of the lib) which will then produce an optimized bundle in the `dist/mylib` folder. Nx [also analyzes](https://nx.dev/latest/angular/plugins/angular/builders/package#updatebuildableprojectdepsinpackagejson) the library’s dependencies and automatically compiles the dependencies in the resulting `package.json` file. + +One particularity when generating a library with `--publishable` is that it requires you to also provide an `--importPath`. Your import path is the actual scope of your distributable package (e.g.: `@myorg/mylib`) - which needs to be a [valid npm package name](https://docs.npmjs.com/files/package.json#name). + +To publish the library (for example to npm) you can run the CLI command: `npm publish` from the artifact located in the `dist` directory. Setting up some automated script in Nx’s `tools` folder may also come in handy. + +For more details on the mechanics, remember that Nx is an open source project, so you can see the actual impact of the schematic by looking at the source code (the best starting point is probably `packages//src/schematics/library/library.ts`). + +## Buildable libraries + +Buildable libraries are similar to "publishable libraries" described above. Their scope however is not to distribute or publish them to some external registry. Thus they might not be optimized for bundling and distribution. + +Buildable libraries are mostly used for producing some pre-compiled output that can be directly referenced from an Nx workspace application without the need to again compile it. A typical scenario is to leverage Nx’s [incremental building](https://nx.dev/latest/angular/guides/ci/incremental-builds) capabilities. + +For more details on the mechanics, remember that Nx is an open source project, so you can see the actual impact of the schematic by looking at the source code (the best starting point is probably `packages//src/schematics/library/library.ts`). diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/creating-libraries.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/creating-libraries.md new file mode 100644 index 0000000000..3cd6c16c57 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/creating-libraries.md @@ -0,0 +1,33 @@ +# Creating Libraries + +Like a lot of decisions in programming, deciding to make a new Nx library or not is all about trade-offs. Each organization will decide on their own conventions, but here are some trade-offs to bear in mind as you have the conversation. + +## Should I Make a New Library? + +There are three main benefits to breaking your code up into more libraries. + +### 1. Faster Commands + +The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected --target=test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently. + +### 2. Visualizing Architecture + +The `nx dep-graph` command generates a graph of how apps and libraries depend on each other. If most of your code lives in a few giant libraries, this visualization doesn't provide much value. + +### 3. Enforcing Constraints + +You can enforce constraints on how different types of libraries depend on each other [using tags](/{{framework}}/workspace/structure/monorepo-tags). Following pre-determined conventions on what kind of code can go in different types of libraries allows your tagging system to enforce good architectural patterns. + +Also, each library defines its own API, which allows for encapsulating logic that other parts of codebase can not access. You can even use a [CODEOWNERS file](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners) to assign ownership of a certain library to a user or team. + +## Should I Add to an Existing Library? + +Limiting the number of libraries by keeping code in an existing library also has benefits. + +### 1. Consolidating Code + +Related code should be close together. If a developer can accomplish a task without moving between multiple different folders, it helps them work faster and make less mistakes. Every new library adds some folders and configuration files that are not directly contributing to business value. Nx helps reduce the cost of adding a new library, but it isn't zero. + +### 2. Removing Constraints + +Especially for rapidly evolving code, the standard architectural constraints may just get in the way of experimentation and exploration. It may be worthwhile to develop for a while in a single library in order to allow a real architecture to emerge and then refactoring into multiple libraries once the pace of change has slowed down. diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/grouping-libraries.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/grouping-libraries.md new file mode 100644 index 0000000000..c844995610 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/grouping-libraries.md @@ -0,0 +1,65 @@ +# Grouping Libraries + +Libraries should be grouped by _scope_. A library's scope is either application to which it belongs or (for larger applications) a section within that application. + +## Move Schematic + +Don't be too anxious about choosing the exact right folder structure from the beginning. Libraries can be moved or renamed using the [`@nrwl/workspace:move` schematic](/{{framework}}/plugins/workspace/schematics/move). + +For instance, if a library under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this: + +```bash +nx g move --project booking-some-library shared/some-library +``` + +## Remove Schematic + +Similarly, if you no longer need a library, you can remove it with the [`@nrwl/workspace:remove` schematic](/{{framework}}/plugins/workspace/schematics/remove). + +```bash +nx g remove booking-some-library +``` + +## Example Workspace + +Let's use Nrwl Airlines as an example organization. This organization has two apps, `booking` and `check-in`. In the Nx workspace, libraries related to `booking` are grouped under a `libs/booking` folder, libraries related to `check-in` are grouped under a `libs/check-in` folder and libraries used in both applications are placed in `libs/shared`. You can also have nested grouping folders, (i.e. `libs/shared/seatmap`). + +The purpose of these folders is to help with organizing by scope. We recommend grouping libraries together which are (usually) updated together. It helps minimize the amount of time a developer spends navigating the folder tree to find the right file. + +```txt +apps/ + booking/ + check-in/ +libs/ + booking/ <---- grouping folder + feature-shell/ <---- library + + check-in/ + feature-shell/ + + shared/ <---- grouping folder + data-access/ <---- library + + seatmap/ <---- grouping folder + data-access/ <---- library + feature-seatmap/ <---- library +``` + +## Sharing Libraries + +One of the main advantages of using a monorepo is that there is more visibility into code that can be reused across many different applications. Shared libraries are a great way to save developers time and effort by reusing a solution to a common problem. + +Let’s consider our reference monorepo. The `shared-data-access` library contains the code needed to communicate with the back-end (for example, the URL prefix). We know that this would be the same for all libs; therefore, we should place this in the shared lib and properly document it so that all projects can use it instead of writing their own versions. + +```txt + libs/ + booking/ + data-access/ <---- app-specific library + + shared/ + data-access/ <---- shared library + + seatmap/ + data-access/ <---- shared library + feature-seatmap/ <---- shared library +``` diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/library-types.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/library-types.md new file mode 100644 index 0000000000..1182992056 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/library-types.md @@ -0,0 +1,110 @@ +# Library Types + +There are many different types of libraries in a workspace. In order to maintain a certain sense of order, we recommend having a small number of types, such as the below four (4) types of libraries. + +**Feature libraries:** + +Developers should consider feature libraries as libraries that implement smart UI (with access to data sources) for specific business use cases or pages in an application. + +**UI libraries:** + +A UI library contains only presentational components (also called "dumb" components). + +**Data-access libraries:** + +A data-access library contains code for interacting with a back-end system. It also includes all the code related to state management. + +**Utility libraries:** + +A utility library contains low-level utilities used by many libraries and applications. + +--- + +## Feature Libraries + +**What is it?** + +A feature library contains a set of files that configure a business use case or a page in an application. Most of the components in such a library are smart components that interact with data sources. This type of library also contains most of the UI logic, form validation code, etc. Feature libraries are almost always app-specific and are often lazy-loaded. + +**Naming Convention** + +`feature` (if nested) or `feature-\*` (e.g., `feature-home`). + +**Dependency Constraints** + +A feature library can depend on any type of library. + +```treeview +libs/ +└── my-app/ + └── feature-home/ + └── src/ + ├── index.ts + └── lib/ +``` + +`feature-home` is the app-specific feature library (in this case, the "my-app" app). + +--- + +## UI Libraries + +**What is it?** + +A UI library is a collection of related presentational components. There are generally no services injected into these components (all of the data they need should come from Inputs). + +**Naming Convention** + +`ui` (if nested) or `ui-\*` (e.g., `ui-buttons`) + +**Dependency Constraints** + +A ui library can depend on ui and util libraries. + +--- + +## Data-access Libraries + +**What is it?** + +Data-access libraries contain code that function as client-side delegate layers to server tier APIs. + +All files related to state management also reside in a `data-access` folder (by convention, they can be grouped under a `+state` folder under `src/lib`). + +**Naming Convention** + +`data-access` (if nested) or `data-access-\*` (e.g. `data-access-seatmap`) + +**Dependency Constraints** + +A data-access library can depend on data-access and util libraries. + +--- + +## Utility Libraries + +**What is it?** + +A utility library contains low level code used by many libraries. Often there is no framework-specific code and the library is simply a collection of utilities or pure functions. + +**Naming Convention** + +`util` (if nested), or `util-\*` (e.g., `util-testing`) + +**Dependency Constraints** + +A utility library can depend only on utility libraries. + +An example ui lib module: **libs/shared/util-formatting** + +```ts +export { formatDate, formatTime } from './src/format-date-fns'; +export { formatCurrency } from './src/format-currency'; +``` + +## Other Types + +You will probably come up with other library types that make sense for your organization. That's fine. Just keep a few things in mind: + +- Keep the number of library types low +- Clearly document what each type of library means diff --git a/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/structure/dependency-graph.md b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/structure/dependency-graph.md new file mode 100644 index 0000000000..9c352090b1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/10.4.13/shared/workspace/structure/dependency-graph.md @@ -0,0 +1,52 @@ +# Analyzing & Visualizing Workspaces + +To be able to support the monorepo-style development, the tools must know how different projects in your workspace depend on each other. Nx uses advanced code analysis to construct this dependency graph. And it gives you a way to explore it: + + + +## How the Dependency Graph is Built + +Nx creates a graph of all the dependencies between projects in your workspace using two sources of information: + +1. Typescript `import` statements referencing a particular project's path alias + + For instance, if a file in `my-app` has this code: + + ```typescript + import { something } from '@myorg/awesome-library'; + ``` + + Then `my-app` depends on `awesome-library` + +2. Manually created `implicitDependencies` in the `nx.json` file. [Full `implicitDependencies` documentation](/{framework}/workspace/configuration#implicit-dependencies) + + If your `nx.json` has this content: + + ```json + { + "projects": { + "my-app": { + "tags": [], + "implicitDependencies": ["my-api"] + } + } + } + ``` + + Then `my-app` depends on `my-api` + +## Circular Dependencies + +A circular dependency is when a project transitively depends on itself. This can cause problems in the design of your software and also makes Nx's affected algorithm less effective. The lint rule, `nx-enforce-module-boundaries`, will produce an error if any circular dependencies are created and ensures that any `import` statements going across projects only `import` from the defined public apis in a project's root `index.ts` file. + +When migrating a new codebase into an nx workspace, you'll likely begin to uncover existing circular dependencies. Let's look at the simplest possible circular dependency, where `projectA` depends on `projectB` and vice versa. + +**To resolve circular dependencies:** + +First, identify the `import` statements causing the dependency. Search in the source folder of `projectA` for references to `@myorg/projectB` and search in the source folder of `projectB` for references to `@myorg/projectA`. + +Then there are three strategies you can use: + +1. Look for small pieces of code that can be moved from one project to the other. +2. Look for code that both libraries depend on and move that code into a new shared library. +3. Combine `projectA` and `projectB` into one library. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/ng-packagr-lite.md new file mode 100644 index 0000000000..050bf6e311 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/ng-packagr-lite.md @@ -0,0 +1,45 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/package.md new file mode 100644 index 0000000000..2981a96842 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/package.md @@ -0,0 +1,45 @@ +# package + +Build and package an Angular library for publishing + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/webpack-browser.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/webpack-browser.md new file mode 100644 index 0000000000..a153abbc7c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/executors/webpack-browser.md @@ -0,0 +1,325 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/application.md new file mode 100644 index 0000000000..91d225fbd6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 `angular.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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/downgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/downgrade-module.md new file mode 100644 index 0000000000..bf61edc6e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup Downgrade Module + +## Usage + +```bash +nx generate downgrade-module ... +``` + +By default, Nx will search for `downgrade-module` in the default collection provisioned in `angular.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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma-project.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma-project.md new file mode 100644 index 0000000000..437525907f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing to a project + +## Usage + +```bash +nx generate karma-project ... +``` + +By default, Nx will search for `karma-project` in the default collection provisioned in `angular.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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma.md new file mode 100644 index 0000000000..60e8a1287f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/karma.md @@ -0,0 +1,23 @@ +# karma + +Add karma configuration to a workspace + +## Usage + +```bash +nx generate karma ... +``` + +By default, Nx will search for `karma` in the default collection provisioned in `angular.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 +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/library.md new file mode 100644 index 0000000000..ee1c4809fc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/library.md @@ -0,0 +1,185 @@ +# library + +Create 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 `angular.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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Type: `string` + +A directory where the lib is placed + +### enableIvy + +Default: `false` + +Type: `boolean` + +Enable Ivy for library in tsconfig.lib.prod.json. Should not be used with publishable libraries. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/move.md new file mode 100644 index 0000000000..8619f74ca3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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 `angular.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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the generator update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/ngrx.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/ngrx.md new file mode 100644 index 0000000000..2b80efe29e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## Usage + +```bash +nx generate ngrx ... +``` + +By default, Nx will search for `ngrx` in the default collection provisioned in `angular.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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/stories.md new file mode 100644 index 0000000000..eb917cdf60 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/stories.md @@ -0,0 +1,37 @@ +# 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 `angular.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 + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-configuration.md new file mode 100644 index 0000000000..395e3800eb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a library + +## Usage + +```bash +nx generate storybook-configuration ... +``` + +By default, Nx will search for `storybook-configuration` in the default collection provisioned in `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library/application? + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..db5fa1d5fd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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 `angular.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 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/data-access-documents/src/data/11.4.0/angular/api-angular/generators/upgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/upgrade-module.md new file mode 100644 index 0000000000..5ef0b73705 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-angular/generators/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add an upgrade module + +## Usage + +```bash +nx generate upgrade-module ... +``` + +By default, Nx will search for `upgrade-module` in the default collection provisioned in `angular.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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/angular/api-cypress/executors/cypress.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-cypress/executors/cypress.md new file mode 100644 index 0000000000..5f0ac9c1ec --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-cypress/executors/cypress.md @@ -0,0 +1,125 @@ +# cypress + +Run Cypress e2e tests + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/11.4.0/angular/api-express/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-express/generators/application.md new file mode 100644 index 0000000000..fa4f5a0ae5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-express/generators/application.md @@ -0,0 +1,115 @@ +# 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 `angular.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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/build.md new file mode 100644 index 0000000000..1e7af3c170 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/build.md @@ -0,0 +1,47 @@ +# build + +Build a Gatsby app + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### color + +Default: `true` + +Type: `boolean` + +Enable colored terminal output. + +### graphqlTracing + +Type: `boolean` + +Trace every graphql resolver, may have performance implications. + +### openTracingConfigFile + +Type: `string` + +Tracer configuration file (OpenTracing compatible). + +### prefixPaths + +Type: `boolean` + +Build site with link paths prefixed (set pathPrefix in your config). + +### profile + +Type: `boolean` + +Build site with react profiling. + +### uglify + +Default: `true` + +Type: `boolean` + +Build site without uglifying JS bundles (true by default). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/server.md new file mode 100644 index 0000000000..9fea830c4d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/executors/server.md @@ -0,0 +1,43 @@ +# server + +Starts server for app + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### https + +Default: `false` + +Type: `boolean` + +Serve using HTTPS. + +### open + +Type: `boolean` + +Open the site in your (default) browser for you. + +### port + +Default: `4200` + +Type: `number` + +Port to listen on. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/application.md new file mode 100644 index 0000000000..6378fe7a59 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/application.md @@ -0,0 +1,89 @@ +# 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 `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/gatsby:application ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g application ... --dry-run +``` + +## Options + +### directory + +Alias(es): d + +Type: `string` + +A directory where the project is placed + +### e2eTestRunner + +Default: `cypress` + +Type: `string` + +Possible values: `cypress`, `none` + +Adds the specified e2e test runner + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files + +### name + +Type: `string` + +### style + +Alias(es): s + +Default: `css` + +Type: `string` + +Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `none` + +The file extension to be used for style files. + +### tags + +Alias(es): t + +Type: `string` + +Add tags to the project (used for linting) + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Adds the specified unit test runner diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/component.md new file mode 100644 index 0000000000..58421410b8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/component.md @@ -0,0 +1,107 @@ +# component + +Create a component + +## Usage + +```bash +nx generate component ... +``` + +By default, Nx will search for `component` in the default collection provisioned in `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/gatsby: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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/page.md new file mode 100644 index 0000000000..f188dae08d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-gatsby/generators/page.md @@ -0,0 +1,107 @@ +# page + +Create a page + +## Usage + +```bash +nx generate page ... +``` + +By default, Nx will search for `page` in the default collection provisioned in `angular.json`. + +You can specify the collection explicitly as follows: + +```bash +nx g @nrwl/gatsby:page ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g page ... --dry-run +``` + +### Examples + +Generate a page in the mylib library: + +```bash +nx g page my-page --project=mylib +``` + +Generate a class component in the mylib library: + +```bash +nx g page my-page --project=mylib --classComponent +``` + +## Options + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-jest/executors/jest.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-jest/executors/jest.md new file mode 100644 index 0000000000..8c3482cd4b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-jest/executors/jest.md @@ -0,0 +1,221 @@ +# jest + +Run Jest unit tests + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-linter/executors/eslint.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-linter/executors/eslint.md new file mode 100644 index 0000000000..30b5a4989b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-linter/executors/eslint.md @@ -0,0 +1,101 @@ +# eslint + +Run ESLint on a project + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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/data-access-documents/src/data/11.4.0/angular/api-linter/executors/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-linter/executors/lint.md new file mode 100644 index 0000000000..24da827c26 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-linter/executors/lint.md @@ -0,0 +1,109 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/11.4.0/angular/api-nest/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/application.md new file mode 100644 index 0000000000..a8033843a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest application + +## Usage + +```bash +nx generate application ... +``` + +```bash +nx g app ... # same +``` + +By default, Nx will search for `application` in the default collection provisioned in `angular.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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/angular/api-nest/generators/class.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/class.md new file mode 100644 index 0000000000..7e17ad9c6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/class.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/controller.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/controller.md new file mode 100644 index 0000000000..f712c2aae2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/controller.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/decorator.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/decorator.md new file mode 100644 index 0000000000..cc261f485a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/decorator.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/filter.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/filter.md new file mode 100644 index 0000000000..7436e2a376 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/filter.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/gateway.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/gateway.md new file mode 100644 index 0000000000..cd34269051 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/gateway.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/guard.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/guard.md new file mode 100644 index 0000000000..62dc698b6c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/guard.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interceptor.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interceptor.md new file mode 100644 index 0000000000..d6bfc25455 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interceptor.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interface.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interface.md new file mode 100644 index 0000000000..eb7aadeefa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/interface.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/library.md new file mode 100644 index 0000000000..7c114d2702 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/library.md @@ -0,0 +1,167 @@ +# library + +Create a new nest library + +## Usage + +```bash +nx generate library ... +``` + +```bash +nx g lib ... # same +``` + +By default, Nx will search for `library` in the default collection provisioned in `angular.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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/angular/api-nest/generators/middleware.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/middleware.md new file mode 100644 index 0000000000..5bf8afa0d9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/middleware.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/module.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/module.md new file mode 100644 index 0000000000..906e7bcb36 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/module.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/pipe.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/pipe.md new file mode 100644 index 0000000000..e12a91f045 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/pipe.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/provider.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/provider.md new file mode 100644 index 0000000000..292cb7f4ae --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/provider.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/resolver.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/resolver.md new file mode 100644 index 0000000000..09b7c8b3f8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/resolver.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/service.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/service.md new file mode 100644 index 0000000000..34731ea862 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nest/generators/service.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/build.md new file mode 100644 index 0000000000..7c3d168a2a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/build.md @@ -0,0 +1,43 @@ +# build + +Build a Next.js app + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/export.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/export.md new file mode 100644 index 0000000000..3bbc6787cb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/export.md @@ -0,0 +1,27 @@ +# export + +Export a Next.js app. The exported application is located at dist/$outputPath/exported. + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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/data-access-documents/src/data/11.4.0/angular/api-next/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/server.md new file mode 100644 index 0000000000..94641914c9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/executors/server.md @@ -0,0 +1,63 @@ +# server + +Serve a Next.js app + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/angular/api-next/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/application.md new file mode 100644 index 0000000000..ac0a2d21b6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/application.md @@ -0,0 +1,131 @@ +# 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 `angular.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. + +### 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) + +### 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. + +### 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/data-access-documents/src/data/11.4.0/angular/api-next/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/component.md new file mode 100644 index 0000000000..a15559d721 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/component.md @@ -0,0 +1,107 @@ +# component + +Create a React component + +## Usage + +```bash +nx generate component ... +``` + +By default, Nx will search for `component` in the default collection provisioned in `angular.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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/angular/api-next/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/page.md new file mode 100644 index 0000000000..913c30ad49 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-next/generators/page.md @@ -0,0 +1,107 @@ +# 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 `angular.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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/angular/api-node/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/build.md new file mode 100644 index 0000000000..462c61069e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/build.md @@ -0,0 +1,161 @@ +# build + +Build a Node application + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/execute.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/execute.md new file mode 100644 index 0000000000..44fe9a5277 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/execute.md @@ -0,0 +1,63 @@ +# execute + +Execute a Node application + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/11.4.0/angular/api-node/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/package.md new file mode 100644 index 0000000000..25b0a23e17 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/executors/package.md @@ -0,0 +1,77 @@ +# package + +Package a Node library + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/angular/api-node/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/generators/application.md new file mode 100644 index 0000000000..e5beb3332a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/generators/application.md @@ -0,0 +1,115 @@ +# 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 `angular.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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/angular/api-node/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/generators/library.md new file mode 100644 index 0000000000..ae4f7d96b2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-node/generators/library.md @@ -0,0 +1,167 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/executors/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/executors/e2e.md new file mode 100644 index 0000000000..6a30dc4b9b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/executors/e2e.md @@ -0,0 +1,25 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/executor.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/executor.md new file mode 100644 index 0000000000..eb3f4bd5e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/executor.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### description + +Alias(es): d + +Type: `string` + +Executor description + +### name + +Type: `string` + +Executor name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/generator.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/generator.md new file mode 100644 index 0000000000..c1c905fe15 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/generator.md @@ -0,0 +1,65 @@ +# 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 `angular.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 + +### description + +Alias(es): d + +Type: `string` + +Generator description + +### name + +Type: `string` + +Generator name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/migration.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/migration.md new file mode 100644 index 0000000000..4b0efe5cbc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/migration.md @@ -0,0 +1,73 @@ +# 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 `angular.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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/plugin.md new file mode 100644 index 0000000000..656fff8080 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-nx-plugin/generators/plugin.md @@ -0,0 +1,97 @@ +# plugin + +Create a Nx Plugin + +## Usage + +```bash +nx generate plugin ... +``` + +By default, Nx will search for `plugin` in the default collection provisioned in `angular.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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/angular/api-react/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/application.md new file mode 100644 index 0000000000..54ff079d1a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/application.md @@ -0,0 +1,173 @@ +# 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 `angular.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. + +### 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. + +### 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. + +### 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). + +### 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/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-cypress-spec.md new file mode 100644 index 0000000000..5496c40fde --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 `angular.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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-story.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-story.md new file mode 100644 index 0000000000..9dc2d510af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component-story.md @@ -0,0 +1,37 @@ +# 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 `angular.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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component.md new file mode 100644 index 0000000000..8868ee5e75 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/component.md @@ -0,0 +1,145 @@ +# component + +Create a component + +## Usage + +```bash +nx generate component ... +``` + +```bash +nx g c ... # same +``` + +By default, Nx will search for `component` in the default collection provisioned in `angular.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 + +### 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. + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/angular/api-react/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/library.md new file mode 100644 index 0000000000..1a81920fc5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/library.md @@ -0,0 +1,181 @@ +# 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 `angular.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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### 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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/angular/api-react/generators/redux.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/redux.md new file mode 100644 index 0000000000..762c61dba7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/redux.md @@ -0,0 +1,67 @@ +# 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 `angular.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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/11.4.0/angular/api-react/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/stories.md new file mode 100644 index 0000000000..986574e2f6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/stories.md @@ -0,0 +1,45 @@ +# 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 `angular.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 + +### 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. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-configuration.md new file mode 100644 index 0000000000..6733d5691d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..fdccfaff0b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-react/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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 `angular.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/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/build.md new file mode 100644 index 0000000000..15d9ae88d2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/build.md @@ -0,0 +1,43 @@ +# build + +Build Storybook + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### 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. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/storybook.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/storybook.md new file mode 100644 index 0000000000..43d622c83c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/executors/storybook.md @@ -0,0 +1,87 @@ +# storybook + +Serve Storybook + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### 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. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/configuration.md new file mode 100644 index 0000000000..e6e78485df --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/configuration.md @@ -0,0 +1,63 @@ +# 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 `angular.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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### 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` + +Library or application name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/cypress-project.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/cypress-project.md new file mode 100644 index 0000000000..d6a486edc3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/cypress-project.md @@ -0,0 +1,49 @@ +# 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 `angular.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 + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..7ec95f19c7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-storybook/generators/migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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 `angular.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/data-access-documents/src/data/11.4.0/angular/api-web/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/build.md new file mode 100644 index 0000000000..2b28fd9e92 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/build.md @@ -0,0 +1,251 @@ +# build + +Build a application + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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. + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/angular/api-web/executors/dev-server.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/dev-server.md new file mode 100644 index 0000000000..e53943a850 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/dev-server.md @@ -0,0 +1,105 @@ +# dev-server + +Serve a web application + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/angular/api-web/executors/file-server.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/file-server.md new file mode 100644 index 0000000000..caa6110847 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/file-server.md @@ -0,0 +1,77 @@ +# file-server + +Serve a web application from a folder + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### buildTarget + +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/data-access-documents/src/data/11.4.0/angular/api-web/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/package.md new file mode 100644 index 0000000000..fd09f76f67 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/executors/package.md @@ -0,0 +1,121 @@ +# package + +Package a library + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### deleteOutputPath + +Default: `true` + +Type: `boolean` + +Delete the output path before building. + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/11.4.0/angular/api-web/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/generators/application.md new file mode 100644 index 0000000000..c7954c442c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-web/generators/application.md @@ -0,0 +1,103 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-commands.md new file mode 100644 index 0000000000..fc0c90dbc8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-commands.md @@ -0,0 +1,219 @@ +# run-commands + +Run any custom commands with Nx + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-script.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-script.md new file mode 100644 index 0000000000..525ac4e725 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/executors/run-script.md @@ -0,0 +1,13 @@ +# run-script + +Run an npm script using Nx + +Properties can be configured in angular.json when defining the executor, or when invoking it. + +## Properties + +### script + +Type: `string` + +Script to run in child process diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/library.md new file mode 100644 index 0000000000..8d29f77b02 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/library.md @@ -0,0 +1,141 @@ +# 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 `angular.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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### strict + +Default: `false` + +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/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/move.md new file mode 100644 index 0000000000..8b76fb8b6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/move.md @@ -0,0 +1,75 @@ +# 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 `angular.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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### 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/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/remove.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/remove.md new file mode 100644 index 0000000000..c641affde7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/remove.md @@ -0,0 +1,71 @@ +# 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 `angular.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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/run-commands.md new file mode 100644 index 0000000000..0ff2c258ac --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/run-commands.md @@ -0,0 +1,73 @@ +# 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 `angular.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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### envFile + +Type: `string` + +Env files to be loaded before executing the commands + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/workspace-generator.md new file mode 100644 index 0000000000..a426f12cf8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/api-workspace/generators/workspace-generator.md @@ -0,0 +1,43 @@ +# 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 `angular.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/data-access-documents/src/data/11.4.0/angular/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/angular/cli/affected-build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-build.md new file mode 100644 index 0000000000..87dbc13855 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-build.md @@ -0,0 +1,133 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/angular/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-e2e.md new file mode 100644 index 0000000000..13992dcca8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-e2e.md @@ -0,0 +1,121 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/angular/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/angular/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-lint.md new file mode 100644 index 0000000000..93c30beaa9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-lint.md @@ -0,0 +1,121 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/angular/cli/affected-test.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-test.md new file mode 100644 index 0000000000..7339dc151c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected-test.md @@ -0,0 +1,121 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/angular/cli/affected.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected.md new file mode 100644 index 0000000000..5b4b792fad --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/affected.md @@ -0,0 +1,143 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/angular/cli/build.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/11.4.0/angular/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/e2e.md new file mode 100644 index 0000000000..279449cf40 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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/data-access-documents/src/data/11.4.0/angular/cli/format-check.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/angular/cli/format-write.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/angular/cli/generate.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/generate.md new file mode 100644 index 0000000000..0fa39dc3f6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/generate.md @@ -0,0 +1,93 @@ +# 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 the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/angular/cli/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/11.4.0/angular/cli/list.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/list.md new file mode 100644 index 0000000000..312250e849 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/migrate.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/angular/cli/print-affected.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/11.4.0/angular/cli/report.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run-many.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run-many.md new file mode 100644 index 0000000000..0a247289e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run-many.md @@ -0,0 +1,97 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/angular/cli/serve.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/11.4.0/angular/cli/test.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/11.4.0/angular/cli/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/workspace-generator.md new file mode 100644 index 0000000000..dca864f7aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/workspace-generator.md @@ -0,0 +1,29 @@ +# workspace-generator + +Runs a workspace generator from the tools/generators directory + +## Usage + +```bash +nx workspace-generator +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/angular/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/apollo-angular.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/apollo-angular.md new file mode 100644 index 0000000000..c6818acd7f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/apollo-angular.md @@ -0,0 +1,12 @@ +# Using Apollo GraphQL with Angular 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 an Angular application to consume your GraphQL api + +**Blog Post:** [Using Apollo GraphQL with Angular in an Nx Workspace](https://blog.nrwl.io/using-apollo-graphql-with-angular-in-an-nx-workspace-9ad0155c1914) + +**Repository:** [nx-apollo-angular-example](https://github.com/nrwl/nx-apollo-angular-example) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected.png new file mode 100644 index 0000000000..e1dd4042dd Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected2.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected2.png new file mode 100644 index 0000000000..3d8f870b93 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-affected2.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-and-angular.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-and-angular.md new file mode 100644 index 0000000000..5539ef330d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-and-angular.md @@ -0,0 +1,471 @@ +# Building Angular and React Applications Together With Nx + +Large companies often use multiple frontend frameworks to build their products. One product can be built with Angular, another one with React. These products, even though are built by different teams using different stacks, often share components and utilities. + +Setting this up traditionally is challenging. Companies put a lot of effort in making sure teams can collaborate and use each other's work. Nx drastically simplifies this. + +To show how Nx does it, let's build two applications (one in Angular, and one in React) that will use a library of shared web components. + +## Creating a New Nx Workspace + +Let's start by creating a new Nx workspace. The easiest way to do this is to use npx. + +```bash +npx --ignore-existing create-nx-workspace happynrwl --preset=empty +``` + +## Add Angular Capabilities + +An empty workspace does not have any capabilities to create applications. Add capabilities for Angular development via: + +```bash +ng add @nrwl/angular +``` + +## Creating an Angular Application + +An empty workspace has no application or libraries: nothing to run and nothing to test. Let's add an Angular application into it via: + +```bash +ng g @nrwl/angular:app angularapp +``` + +The result should look like this: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ │ ├── app.components.css +│ │ │ │ ├── app.components.html +│ │ │ │ ├── app.components.spec.ts +│ │ │ │ ├── app.components.ts +│ │ │ │ └── app.module.ts +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ ├── styles.scss +│ │ │ └── test.ts +│ │ ├── jest.conf.js +│ │ ├── tsconfig.app.json +│ │ ├── browserslist +│ │ ├── tsconfig.json +│ │ ├── tsconfig.spec.json +│ │ └── tslint.json +│ └── angularapp-e2e/ +│ ├── src/ +│ │ ├── integrations/ +│ │ │ └── app.spec.ts +│ │ ├── fixtures/ +│ │ ├── plugins/ +│ │ └── support/ +│ ├── cypress.json +│ ├── tsconfig.e2e.json +│ └── tslint.json +├── libs/ +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +The generated `main.ts`, will look as follows: + +```typescript +import { enableProdMode } from '@angular/core'; + +import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; +import { AppModule } from './app/app.module'; + +import { environment } from './environments/environment'; + +if (environment.production) { + enableProdMode(); +} + +platformBrowserDynamic() + .bootstrapModule(AppModule) + .catch((err) => console.error(err)); +``` + +And the template of the generated component will look as follows: + +```html +
+ Welcome to {{title}}! + +
+ +

This is an Angular app built with Nx.

+``` + +## Adding React Capabilities + +Generating a React application is just as easy. First, add capabilities for React development via: + +```bash +ng add @nrwl/react +``` + +## Creating a React Application + +Create a React application via: + +`ng g @nrwl/react:app reactapp` and this is what we will see: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ ├── angularapp-e2e/ +│ ├── reactapp/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ │ ├── app.css +│ │ │ │ ├── app.spec.tsx +│ │ │ │ └── app.tsx +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ ├── styles.scss +│ │ │ └── test.ts +│ │ ├── browserslist +│ │ ├── jest.conf.js +│ │ ├── tsconfig.app.json +│ │ ├── tsconfig.json +│ │ ├── tsconfig.spec.json +│ │ └── tslint.json +│ └── reactapp-e2e/ +│ ├── src/ +│ │ ├── integrations/ +│ │ │ └── app.spec.ts +│ │ ├── fixtures/ +│ │ ├── plugins/ +│ │ └── support/ +│ ├── cypress.json +│ ├── tsconfig.e2e.json +│ └── tslint.json +├── libs/ +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Where `main.ts` looks like this: + +```typescript +import * as React from 'react'; +import * as ReactDOM from 'react-dom'; + +import { App } from './app/app'; + +ReactDOM.render(, document.querySelector('happynrwl-root')); +``` + +and `app.tsx` contains the following component: + +```typescript jsx +import * as React from 'react'; +import { Component } from 'react'; + +import './app.css'; + +export class App extends Component { + render() { + const title = 'reactapp'; + return ( +
+
+

Welcome to {title}!

+ +
+

+ This is a React app built with Nx. +

+
+ ); + } +} +``` + +Nx provides a uniform tool for development the commands used for React development are the same as the commands used to develop Angular applications. + +- `ng serve reactapp` serves the React app +- `ng build reactapp` builds the React app +- `ng test reactapp` tests the React app using Jest +- `ng e2e reactapp-e2e` tests the React app using Cypress + +TypeScript support, Jest, Cypress, source maps, watch mode--all work with React out of the box. If we run ng serve reactapp, we will see the following: + +![serve screenshot](/assets/content/angular/examples/react-serve.png) + +## Creating Shared Components + +Nx makes sharing code between applications easy. What used to take days or even weeks, with Nx takes minutes. Say we want to create a ui library of shared components that we will use in both the React and Angular applications. + +`ng g @nrwl/workspace:lib ui` and this is what we will see: + +```treeview +happynrwl/ +├── apps/ +│ ├── angularapp/ +│ ├── angularapp-e2e/ +│ ├── reactapp/ +│ └── reactapp-e2e/ +├── libs/ +│ └── ui +│ ├── src/ +│ │ ├── lib/ +│ │ └── index.ts +│ ├── jest.conf.js +│ ├── tsconfig.lib.json +│ ├── tsconfig.json +│ ├── tsconfig.spec.json +│ └── tslint.json +├── README.md +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Let's create a `greeting.element.ts` in the lib folder: + +```typescript +export class GreetingElement extends HTMLElement { + public static observedAttributes = ['title']; + + attributeChangedCallback() { + this.innerHTML = `

Welcome to ${this.title}!

`; + } +} + +customElements.define('happynrwl-greeting', GreetingElement); +``` + +and reexport it in the `index.ts` file: + +```typescript +export * from './lib/greeting.element'; +``` + +The updated library should look like this + +```treeview +happynrwl/ +├── apps/ +├── libs/ +│ └── ui +│ ├── src/ +│ │ ├── lib/ +│ │ │ └── greeting.element.ts +│ │ └── index.ts +│ ├── jest.conf.js +│ ├── tsconfig.lib.json +│ ├── tsconfig.json +│ ├── tsconfig.spec.json +│ └── tslint.json +├── ... +``` + +## Using the Greeting Element in our Angular App + +### Importing the Library + +Next, let's include the new library. + +```typescript +import '@happynrwl/ui'; // <-- the new library + +import { enableProdMode } from '@angular/core'; + +import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; +import { AppModule } from './app/app.module'; + +import { environment } from './environments/environment'; + +if (environment.production) { + enableProdMode(); +} + +platformBrowserDynamic() + .bootstrapModule(AppModule) + .catch((err) => console.error(err)); +``` + +### Registering CUSTOM_ELEMENTS_SCHEMA + +Next, let's register the `CUSTOM_ELEMENTS_SCHEMA` schema, which will tell the Angular compiler not to error when seeing non-standard element tags in components' templates. + +```typescript +@NgModule({ + declarations: [AppComponent], + imports: [BrowserModule], + providers: [], + schemas: [CUSTOM_ELEMENTS_SCHEMA], + bootstrap: [AppComponent], +}) +export class AppModule {} +``` + +### Using the Greeting Element + +Finally, we can update `app.component.html` to use our shared web component. + +```html +
+ + +
+ +

This is an Angular app built with Nx.

+``` + +## Using the Greeting Element in our React App + +Using Greeting in the react app requires similar steps. + +### Importing Library + +Next, let's include the new library in `main.ts`. + +```typescript jsx +import '@happynrwl/ui'; + +import * as React from 'react'; +import * as ReactDOM from 'react-dom'; + +import { App } from './app/app'; + +ReactDOM.render(, document.querySelector('happynrwl-root')); +``` + +### Adding Intrinsic Types + +Instead of registering `CUSTOM_ELEMENTS_SCHEMA`, let's add `intrinsic.d.ts file`, which serves a similar purpose to `CUSTOM_ELEMENTS_SCHEMA`, next to `main.tsx`. + +```typescript +declare namespace JSX { + interface IntrinsicElements { + [elemName: string]: any; + } +} +``` + +### Using the Greeting Element + +Finally, we can update `app.tsx` to use our shared web component. + +```typescript jsx +import * as React from 'react'; +import { Component } from 'react'; + +import './app.css'; + +export class App extends Component { + render() { + const title = 'reactapp'; + return ( +
+
+ + +
+

+ This is a React app built with Nx. +

+
+ ); + } +} +``` + +## Nx Intelligence + +What we have shown is already quite remarkable. We built two applications in two different framework using a shared library of web components. We can use same commands to serve, build, test the applications. + +But Nx can do a lot more than that. + +If we run `yarn dep-graph`, we will see the following: + +![serve screenshot](/assets/content/angular/examples/react-dep-graph.png) + +Nx understands how our applications and libraries depend on each other. This is extremely important! To really improve the collaboration between teams and make sure that they can use each other's work, the following two things must be true: + +- If the Angular team makes a change to the Angular app itself. Only the Angular app has to be rebuilt and retested. Same is true for the React team. Any tool that requires us to rebuild and retest everything on every PR won't scale beyond a small repository. +- If any of the teams changes the ui library, both the Angular and the React applications should be rebuilt and retested before the PR gets merged into master. This is the only way to guarantee that the PR is safe to merge. + +To see how Nx helps with this, let's commit the changes we have made so far. + +```bash +git add . +git commit -am 'great commit' +``` + +Next, let's create a new branch `git checkout -b angularchange`. In this branch, let's introduce any change to app.component.html and run `yarn affected:dep-graph`. + +![serve screenshot](/assets/content/angular/examples/react-affected.png) + +As you can see, Nx knows that this change only affects the `angularapp` and nothing else. Nx can use this information to rebuild and retest only the angularapp: + +```bash +yarn affected:test # only tests angularapp +yarn affected:build # only builds angularapp +``` + +Now, let's introduce a change to `greeting.element.ts` and run `yarn affected:dep-graph`. + +![serve screenshot](/assets/content/angular/examples/react-affected2.png) + +Both `angularapp` and `reactapp` are affected by this change because they both depend on the greeting component. + +```bash +yarn affected:test # tests ui, angularapp, reactapp +yarn affected:build # only builds angularapp, reactapp +``` + +This is what we just saw: + +- If we only touch our code, we only have to retest and rebuild our code. +- If we touch something that affects other teams, we'll have to rebuild and retest their applications as well. + +Because this is a simple example, the impact is easily deductible. But a real workspace can have a dozen applications and hundred of libraries. Ad-hoc solutions do not work at such scale--we need tools like Nx, that can help us manage those workspaces. + +## Summary + +With Nx, we can build multiple applications using different frontend frameworks in the same workspace. These applications can share components, services, utilities. In this example we looked at a library of web components that we used in Angular and React applications. But we could go further: we could build the shared component using Angular Elements and then use it in the React application. Nx also allows us to build the backend next to our frontend and share code between them. + +Nx analyses the code base to figure out how libraries and applications depend on each other. This analysis happens across frameworks and across client-server boundaries. + +## Example App + +You can find the example application [here](https://github.com/nrwl/nx-angular-and-react). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-dep-graph.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-dep-graph.png new file mode 100644 index 0000000000..81f04e4632 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-dep-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-serve.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-serve.png new file mode 100644 index 0000000000..b73ca2038a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/examples/react-serve.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/executors.json b/nx-dev/data-access-documents/src/data/11.4.0/angular/executors.json new file mode 100644 index 0000000000..ded073647f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/executors.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/generators.json b/nx-dev/data-access-documents/src/data/11.4.0/angular/generators.json new file mode 100644 index 0000000000..46a738dc38 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/generators.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "nest", + "next", + "node", + "nx-plugin", + "react", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/create-workspace.gif b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/create-workspace.gif new file mode 100644 index 0000000000..85a97af73b Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/create-workspace.gif differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/dep-graph.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/dep-graph.png new file mode 100644 index 0000000000..0cc9c65cdf Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/dep-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/getting-started.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/getting-started.md new file mode 100644 index 0000000000..f4e4d69874 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/getting-started.md @@ -0,0 +1,28 @@ +# Getting Started + +Nx is a suite of powerful, extensible dev tools that help you develop, test, build, and scale Angular applications with fully integrated support for modern libraries like Jest, Cypress, ESLint, NgRx, and more. + +## 10-Minute Nx Overview + + + +## Create Nx Workspace + +Creating an Nx workspace is easy. Run the following command to set up an Nx workspace with an Angular app in it. + +```bash +npx create-nx-workspace --preset=angular +``` + +## Learn Nx Fundamentals + +- [Interactive Nx Tutorial (with videos)](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) +- [45-Minute Walkthrough on YouTube](https://www.youtube.com/watch?v=h5FIGDn5YM0) + +## Dive Deep + +- [Nx CLI](/{{framework}}/getting-started/cli-overview) +- [Configuration Files](/{{framework}}/getting-started/configuration) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/nx-and-cli.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/nx-and-cli.md new file mode 100644 index 0000000000..6645f78bbd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/nx-and-cli.md @@ -0,0 +1,11 @@ +# Nx and Angular CLI + +Nx supports Angular Devkit. When you run `nx build myapp`, and the build target for `myapp` is implemented using Angular Devkit, Nx will do exactly the same as the Angular CLI. When you run `nx g component mycmp`, once again, Nx will invoke the same schematic. You can think of Nx wrapping the Angular CLI. The results of running commands will produce the same result, except that running `nx` will often be a lot faster. + +How? + +Nx CLI uses advanced code analysis and computation caching to reuse previous computation results when possible. The Angular CLI doesn't do it. The `Nx CLI` also supports a lot more commands than the Angular CLI. It can run a target against many projects in parallel, run a target against a project and its dependencies, etc.. + +## Decorating Angular CLI + +Since Nx does everything Angular CLI does, but better, all workspace have a `decorate-angular-cli.js` file. This file remaps `ng` to invoke `nx`, which at the end of the day still invokes the Angular CLI. In other words, calling `ng` will invoke the wrapped version. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/resources.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/resources.md new file mode 100644 index 0000000000..a58b2d2132 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/getting-started/resources.md @@ -0,0 +1,75 @@ +# Resources + +## Quick Introductions (10 Minutes) + + + +## 45-Minute Walkthrough + + + +## Nx Console Overview + + + +## Courses + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## Resources + +### Highlights + +- [Nrwl Talks, Presentations, and Podcasts playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dHHWx4JIORwfnEajRv6FG5m) + +- [Nx Blog Posts](https://blog.nrwl.io/nx/home) + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [Nx Office Hours playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dE8KLQ5zd3fQwu_yQHjTmR5) + +### Nx Demo & Tutorial Videos + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (Angular)](https://youtu.be/h5FIGDn5YM0) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Nx Console - A Must-Have Visual Studio Code Extension for Angular Developers](https://youtu.be/IIetmfgozgI) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +### Books and Blogs + +- [Angular Enterprise Monorepo Patterns Book (free)](https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book?utm_campaign=Book%3A%20Monorepo%20Patterns%2C%20Jan%202019&utm_source=Github&utm_medium=Banner%20Ad) + +- [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +- [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +- [Tiny Angular application projects in Nx workspaces](https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/#peer-reviewers--30/) (March 2020) + +### Additional Resources + +- [xplat - Cross-platform tools for Nx workspaces](https://nstudio.io/xplat/) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/cli-overview.md new file mode 100644 index 0000000000..40c80c8b73 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/cli-overview.md @@ -0,0 +1,324 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Nx CLI and Angular CLI + +The Nx CLI supports different types of generators and executors. When running Angular Devkit schematics (e.g., generating an Angular component), the Nx CLI will use Angular Devkit under the hood. So the result will be exactly the same as if you used the Angular CLI. When running Angular Devkit builders, the Nx CLI once again will use the same Angular Devkit under the hood. + +In other words, anything the Angular CLI can run, the Nx CLI can run as well because it uses the same Angular Devkit written by the Angular team under the hood. Except that using the Nx CLI is often a lot faster because of its powerful computation caching and code change analysis. + +The `Nx CLI` also supports a lot more commands than the Angular CLI. It can run a target against many projects in parallel, run a target against a project and its dependencies, visualize the dependency graph etc.. + +Nx will create the `decorate-angular-cli.js` file in a new Nx workspace. This file essentially "wraps" the Angular CLI to give you computation caching and other powerful feature, so running `nx build myapp` and `ng build myapp` will produce the same result. + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/angular`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called generators. Generators provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/angular:application myapp +``` + +The `@nrwl/angular` package contains a collection of generators, with `application` being the one used in this example. The Nx CLI applies the generator to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the generator. + +```sh +nx generate @nrwl/angular:application myapp --style=scss +``` + +You can preview the changes a generator makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the generator. + +**Generate command:** + +`nx generate` runs generators to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[generator-name] [options]` + Example: `nx generate @nrwl/angular:component mycmp --project=myapp` + +## Running Tasks + +The Nx CLI uses builders to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +A builder is a function that uses the Architect API to perform a complex process such as "build", "test", or "lint". + +You can configure the builders in `angular.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "architect": { + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` builder, and the `test` target uses `@nrwl/jest:jest`. Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # production configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any builders you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the builder. + +```sh +nx affected --target=build --prod +``` + +## 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` +3. `workspaceRoot/.local.env` +4. `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 `.local.env` files for their local environment and override any project defaults set in `.env` + +For example: + +1. `workspaceRoot/apps/my-app/.local.env` 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/.local.env` 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](/{{framework}}/core-concepts/computation-caching#nx-cloud-and-distributed-computation-memoization)). + +### 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](/{{framework}}/workspace/run-commands-executor#envfile) builder and execute your command inside of the builder + +## ng add Functionality + +To run the equivalent of the Angular CLI's `ng add` command for a package named `my-package`, you need to run two commands: + +```shell script +# npm +npm i my-package +nx g my-package:ng-add +``` + +```shell script +# yarn +yarn add my-package +nx g my-package:ng-add +``` + +Note: The plugins maintained by Nrwl have `init` as an alias for `ng-add`, so you can run `nx g @nrwl/angular:init` or `nx g @nrwl/angular:ng-add`. + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/configuration.md new file mode 100644 index 0000000000..0e35f8034c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/configuration.md @@ -0,0 +1,365 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `angular.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## angular.json + +The `angular.json` configuration file contains information about the targets and generators. Let's look at the following example: + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "myapp:build", + "proxyConfig": "apps/myapp/proxy.conf.json" + } + }, + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js", + "tsConfig": "apps/myapp/tsconfig.spec.json" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": { + "test": { + "builder": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/web" + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "architect": {} + } +} +``` + +- `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'. +- `architect` configures all the targets which define what tasks you can run against the library. + +> Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular. + +### Targets + +Let's look at the simple architect target: + +```json +{ + "test": { + "builder": "@nrwl/jest:jest", + "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 run mylib:mytest`. + +**Builder** + +The `builder` 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 builder named `jest` and invoke it with the options. + +**Options** + +The `options` provides a map of values that will be passed to the builder. 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 builder: + +```json +{ + "jestConfig": "libs/mylib/another-jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" +} +``` + +**Outputs** + +The `outputs` property lists the folders the builder will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + } +} +``` + +You can select a configuration like this: `nx build myapp --configuration=production` or `nx run myapp:build:configuration=production`. + +The following show how the builder options get constructed: + +```bash +require(`@nrwl/jest`).builders['jest']({...options, ...selectedConfiguration, ...commandLineArgs}}) // Pseudocode +``` + +The selected configuration adds/overrides the default options, and the provided command line args add/override the configuration options. + +### Generators + +Generators that are created using `@angular-devkit` are called schematics. You can configure default generator options in `angular.json` as well. For instance, the following will tell Nx to always pass `--style=scss` when creating new libraries. + +```json +{ + "schematics": { + "@nrwl/angular:library": { + "style": "scss" + } + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/angular:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/angular" + } +} +``` + +### workspace.json + +Your `angular.json` file can be renamed to `workspace.json` and Nx will process it in the same way. The `workspace.json` has one additional top level property `version`. Setting `version` to 1 means the `workspace.json` file syntax is identical to `angular.json` When the `version` of `workspace.json` is set to 2, `targets`, `generators` and `executor` properties are used instead of the version 1 properties `architect`, `schematics` and `builder`. + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "angular.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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. + +### 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 dependencies between shared files and projects cannot be inferred statically. You can configure those using `implicitDependencies`. + +```json +{ + "implicitDependencies": { + "angular.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": { + "mypackage": ["mylib"] + }, + "scripts": { + "check:*": "*" + } + }, + "globalFile": ["myapp"], + "styles/**/*.css": ["myapp"] + } +} +``` + +In the example above: + +- Changing `angular.json` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +## .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 will not be taken into account in the `affected` calculations. +2. Even if the file is outside an app or library, `nx workspace-lint` will not warn about it. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-data-persistence.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-data-persistence.md new file mode 100644 index 0000000000..d5f0bdd266 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-data-persistence.md @@ -0,0 +1,216 @@ +# 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/data-access-documents/src/data/11.4.0/angular/guides/misc-ngrx.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-ngrx.md new file mode 100644 index 0000000000..65f5c2f023 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-ngrx.md @@ -0,0 +1,119 @@ +# 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](/{{framework}}/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/data-access-documents/src/data/11.4.0/angular/guides/misc-upgrade.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-upgrade.md new file mode 100644 index 0000000000..b840a29028 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/misc-upgrade.md @@ -0,0 +1,99 @@ +# Upgrading AngularJS Applications + +There are two main ways to incrementally upgrade your AngularJS application: using UpgradeModule and using downgradeModule. Nx helps you use both. + +## Using UpgradeModule + +NgUpgrade is a library put together by the Angular team, which we can use in our application to mix and match AngularJS and Angular components and bridge the AngularJS and Angular dependency injection systems. We can call such an application a “hybrid application”, and the code required to bootstrap it an "upgrade module". + +Setting up an Upgrade Module manually involves several steps and is easy to misconfigure. **Nx** provides a command that does it for you. + +```console +ng g @nrwl/angular:upgrade-module legacyApp --project=myapp +``` + +This will add and set up `UpgradeModule`, configure `legacyApp`, and will add all the needed dependencies to `package.json`. + +Open the generated `legacy-app-setup.ts` and you will find all the code needed to bridge the AngularJS and Angular applications. + +### Testing Hybrid Applications + +For a lot of applications, just running one command is sufficient to convert your application into a hybrid application. That's not always the case--sometimes changes are required. To make this iterative process easier, Nx creates `hybrid.spec.ts`, which you can use to make sure the upgrade module works. + +### After Upgrade Module + +Nx sets up the upgrade module for you to help you get started with your upgrade process. To learn more on how to upgrade your application, once an upgrade module is set up, check out the following resources: + +#### Talk: Upgrading Enterprise Angular Applications + +In this talk at NgConf, Victor Savkin shows how to upgrade your application gradually, component by component, module by module using NgUpgrade and the Angular Router. He discusses the common problems developers face during such migrations and the patterns that can be used to remedy them. + +Embedded content: https://www.youtube.com/embed/izpqQpD8RQ0 + +#### Blog: Upgrading Angular Applications + +In this blog post series Victor Savkin covers similar topics but more in depth. He dives deep into NgUpgrade, including the mental model, implementation, subtleties of the API. Then he talks about different strategies for upgrading large AngularJS applications. + +- [NgUpgrade in Depth](https://blog.nrwl.io/ngupgrade-in-depth-436a52298a00) +- [Upgrade Shell](https://blog.nrwl.io/upgrading-angular-applications-upgrade-shell-4d4f4a7e7f7b) +- [Two Approaches to Upgrading Angular Applications](https://blog.nrwl.io/two-approaches-to-upgrading-angular-apps-6350b33384e3) +- [Managing Routers and URL](https://blog.nrwl.io/upgrading-angular-applications-managing-routers-and-url-ca5588290aaa) +- [Using NgUpgrade like a Pro: Lazy Loading AngularJS Applications](https://blog.nrwl.io/using-ngupgrade-like-a-pro-lazy-loading-angularjs-applications-469819f5c86) + +## Using downgradeModule + +While NgUpgrade provides a way to run Angular and AngularJS code side by side and bridge the dependency injection systems, it does take a bit of a performance hit. Reason being, you end up having both change detection systems running at the same time regardless of if you are hitting Angular or AngularJS code. + +The Angular upgrade package provides a way to do "NgUpgrade Lite", which is the concept of running AngularJS and downgrading Angular to run when needed, as well as keeping the change detection systems separate. Angular change detection will only run on Angular code and AngularJS scope digest will only run on AngularJS code. + +For finer grain control over application performance during conversion to Angular, the downgrade module approach is a good choice. + +Setting up a Downgrade Module manually involves several steps and is easy to misconfigure. **Nx** provides a command that does it for you. + +```console +ng @nrwl/angular:downgrade-module legacyApp --project=myapp +``` + +This will configure the `AppModule` to not bootstrap the `AppComponent` and instead set it up as an entry component. It will also configure `main.ts` to bootstrap AngularJS and use the `downgradeModule` to downgrade the Angular `AppModule` to run in AngularJS. + +Open `main.ts` and you will find all the code needed to run AngularJS and include Angular code. + +### After Downgrade Module + +Nx sets up the downgrade module for you to help you get started with your conversion process to Angular. Check out the blog post on [Using Nrwl/Nx to Upgrade You AngularJS Applications to Angular](https://blog.nrwl.io/using-nrwl-nx-to-upgrade-you-angularjs-applications-to-angular-f5b8adf188aa) to learn more about the differences between Upgrade and Downgrade Module. + +From there, a good next step is to pick a slicing strategy for taking on incremental upgrades. To learn about the vertical and horizontal slicing strategies check out [Two Approaches to Upgrading Angular Applications](https://blog.nrwl.io/two-approaches-to-upgrading-angular-apps-6350b33384e3). + +#### Upgrading/Downgrading Injectables and Components + +Once you have decided on a slicing strategy you will move forward with converting AngularJS components (directives) and injectables to Angular and downgrading them to use them in the AngularJS bits as well as upgrading some of the AngularJS bits to be able to run in the Angular ones. The blog post [NgUpgrade in Depth](https://blog.nrwl.io/ngupgrade-in-depth-436a52298a00) includes information on handling injectable and component conversions to Angular, which are the same way to do it for the Downgrade Module approach. Take a look at the sections on **Dependency Injection** and **Component Integration** to learn how to upgrade/downgrade injectables and components for use in AngularJS and Angular. + +#### Controlling Change Detection + +The other piece of the puzzle that you will need to handle is manually triggering change detection if your component tree consists of a combination of AngularJS and Angular components. + +If you have an Angular component that has an AngularJS child component you may need to inject in `$rootScope` and call `$digest` after your Angular component does something to get the child AngularJS component to update: + +```typescript +@Component({ + selector: 'app-ticket-list', + templateUrl: './ticket-list.component.html', + styleUrls: ['./ticket-list.component.css'], +}) +export class TicketListComponent implements OnInit { + @Input() tuskTickets; + notifyList = []; + + constructor(@Inject('$rootScope') private rootScope: any) {} + + onNotifyAll() { + this.notifyList = this.tuskTickets.map(function (t) { + return t.id; + }); + // we need to force digest to trigger angularjs change detection + this.rootScope.$digest(); + } +} +``` + +Since the two change detection systems are kept separate in the Downgrade Module approach, you have to handle telling the other to run if the one you are in needs to affect the other. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/karma-to-jest.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/karma-to-jest.md new file mode 100644 index 0000000000..4e89788539 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/karma-to-jest.md @@ -0,0 +1,102 @@ +# Migrating from Karma to Jest + +By default, the Angular CLI provides Karma as a test runner and Jasmine as the test framework. Nx offers the choice of using Jest for both runner and framework. If a library in your Angular workspace was created to use Karma, there are three steps to migrate to Jest: + +## 1. Add Jest support to the workspace + +The following command adds Jest support to the workspace. This only needs to be performed once per workspace. You can skip this step if Jest is already added to the workspace. + +```bash +ng generate jest +``` + +## 2. Replace Karma config with Jest config files for a lib + +Assuming we have the default configuration produced by the Angular CLI, we need to perform the following operations: + +**Step 1** + +Delete `karma.conf.js` from the lib's folder. If you have custom code or options here you will need to make a copy so that you can try to recreate this behavior with Jest in `src/jest.config.js` after step 4. + +**Step 2** + +Delete `src/test.ts`. Again if you have custom code in here you will need to make a copy and recreate the behavior after Step 4 in the `src/lib/test-setup.ts`. + +**Step 3** + +Remove the test section for the project in your `angular.json` or `workspace.json`: + +```json +: { + "architect": { + "test": { + "builder": "@angular-devkit/build-angular:karma", + "options": { + "main": "libs/shared/view-component/src/test.ts", + "tsConfig": "libs/shared/view-component/tsconfig.spec.json", + "karmaConfig": "libs/shared/view-component/karma.conf.js" + } + } + } +} +``` + +**Step 4** + +```bash +ng generate jest-project --project +``` + +Any custom code that was present in Step 1 and 2 should be recreated now in the new Jest config files that were generated by this command. + +**Step 5** + +Modify `tsconfig.spec.ts` in the lib’s folder and add Jest typings: add jest under types and remove previous framework (e.g. jasmine) + +```bash +"types": [ "jest", "node" ] +``` + +## 3. Migrate spec files to Jest + +This step is very manual and varies widely based on the usage of features from various frameworks. Below are some common migrations for Jasmine. Jest’s API is very close to Jasmine’s but there are some differences. + +**Spies** + +- Bare spies + - Jasmine + ```typescript + const myMock = jasmine.createSpy('myMock); + ``` + - Jest + ```typescript + const myMock = jest.fn(); + ``` +- Spies on existing objects + - Jasmine + ```typescript + spyOn(foo, 'setBar'); + ``` + - Jest + ```typescript + jest.spyOn(foo, ‘setBar’); + ``` + +It’s a good practice to avoid relying on `spyOn` being global and instead using `jest.spyOn`. The behavior of the Jest spies is different from the Jasmine spies in the following ways: + +- The method being spied on is called by default in Jest, similar to Jasmine’s `spyOn(foo, ‘setBar’).and.callThrough();` To avoid calling through to the original function, set the `mockImplementation` to override it: `jest.spyOn(foo, ‘setBar’).mockImplementation(() => {})`. This is similar to Jasmine’s `spyOn(foo, ‘setBar’).and.callFake` +- Jasmine’s `spyOn(foo, "getBar").and.returnValue(745);` would become `jest.spyOn(foo, ‘setBar’).mockImplementation(() => 745)` in Jest + +It is worth looking at the documentation for Jasmine (or your previous test framework) and compare against the Jest documentation - most functionality should be supported but some code changes might be needed. + +**Marbles: `hot` and `cold`** + +`@nrwl/nx/testing` exports `hot` and `cold` from `jasmine-marbles`. We now need to import these from `jest-marbles` instead. + +At this point, the spec files might have issues that need to be fixed before tests can be run: the linter will highlight these issues. + +Once the spec files have been fixed we can run the tests (using Jest): + +```bash +ng test +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/protractor-to-cypress.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/protractor-to-cypress.md new file mode 100644 index 0000000000..dd6b8d7d2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/modern-angular/protractor-to-cypress.md @@ -0,0 +1,42 @@ +# Migrating from Protractor to Cypress + +Nx helps configure your e2e tests for you. When running the Nx generator to create a new app, you can choose Protractor as an option, but the default is Cypress. If you have an existing set of e2e tests using Protractor and would like to switch to using Cypress, you can follow these steps. + +Let's say your existing app is named `my-awesome-app` and the e2e Protractor tests are located in `my-awesome-app-e2e`. + +0. Before you start, make sure you have a clean git working tree (by committing or stashing any in progress changes) +1. Create a throw away app named `delete-this-app` using `Cypress` for the e2e setting. + ```bash + nx g @nrwl/angular:application --name=delete-this-app --e2eTestRunner=cypress + ``` +2. Rename `apps/my-awesome-app-e2e/src` to `apps/my-awesome-app-e2e/src-protractor` + ```bash + mv apps/my-awesome-app-e2e/src apps/my-awesome-app-e2e/src-protractor + ``` +3. Move the contents of `apps/delete-this-app-e2e` to `apps/my-awesome-app-e2e` + ```bash + mv apps/delete-this-app-e2e/* apps/my-awesome-app-e2e + ``` +4. In the `angular.json` (or `workspace.json`) file copy the `e2e` target configuration for `delete-this-app-e2e` and use that to replace the `e2e` target configuration for `my-awesome-app-e2e`. In the new configuration section, replace any instance of `delete-this-app` with `my-awesome-app`. +5. Delete `delete-this-app` and `delete-this-app-e2e` + ```bash + nx g rm delete-this-app-e2e + nx g rm delete-this-app + ``` +6. Edit `apps/my-awesome-app-e2e/cypress.json` and replace any instance of `delete-this-app` with `my-awesome-app`. +7. Delete `apps/my-awesome-app-e2e/protractor.conf.js` + ```bash + rm apps/my-awesome-app-e2e/protractor.conf.js + ``` +8. Migrate your `*.po.ts` files to use the Cypress API as opposed to the Protractor API. + + - The canonical way for Cypress to handle page objects is to create small reusable functions that use the `cy` object to return a reference to whatever element you want to interact with. + +9. Migrate your Protractor `*.spec.ts` files to Cypress `*.spec.ts` files. + + - Refer to the excellent [Cypress docs](https://docs.cypress.io/) for more information. + +10. Run your Cypress tests with the same command that launched your Protractor tests. + ```bash + nx e2e my-awesome-app-e2e + ``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/nx-devkit-angular-devkit.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/nx-devkit-angular-devkit.md new file mode 100644 index 0000000000..4453711f4c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/nx-devkit-angular-devkit.md @@ -0,0 +1,139 @@ +# Nx Devkit and Angular Devkit + +> Note: this document covers the difference between Nx Devkit and Angular Devkit. See the [Nx Devkit](/{{framework}}/core-concepts/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). An Angular schematic is a second way to implement generators. An Angular builder is a second way to implement an executor. + +What is the difference 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, optoins: 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), + ]); +} +``` + +**Some notable changes:** + +- 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. Just invoke the helpers directly. This makes them more debuggable. As you step through the generator you can see the tree being updated. +- `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. +- You don't need any special helpers to compose Nx Devkit generators. You do need to go through a special resolution step to compose Angular Schematics. +- No special utilities are needed to test Nx Devkit generators. Special utilities are needed to test Angular Schematics. + +The schema files for both Nx Devkit generators and Angular Schematics are the same. Nx can run both of them in the same way. You can invoke Angular schematics from within Nx Devkit generators using `wrapAngularDevkitSchematic`. + +## 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 default function ( + 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); +``` + +Some notable changes: + +- 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](/{{framework}}/core-concepts/nx-devkit#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/data-access-documents/src/data/11.4.0/angular/guides/nx7-to-nx8.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/nx7-to-nx8.md new file mode 100644 index 0000000000..3e90951609 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/nx7-to-nx8.md @@ -0,0 +1,110 @@ +# Nx 7 => Nx 8 + +If you have used Nx since before version 8, things might seem different now. Prior to Nx 8 our packages were `@nrwl/schematics` and `@nrwl/builders`. These packages were organized by which Angular CLI feature they depended on. `@nrwl/schematics` contained the core of Nx + schematics for all of our features: Angular, React, Node, and Nest. This organization had very little meaning to users and made it impossible to install only capabilities needed for Angular. To solve this, in Nx 8, we have organized our packages by feature. + +## Upgrading from Nx 7 to Nx 8 + +To upgrade from a Nx 7 workspace to a Nx 8 workspace, run: + +- `ng update @nrwl/schematics@8.4.8` to update the workspace to the Nx 8 format. +- Commit the results +- `ng update @nrwl/workspace@8.4.8` to update the workspace to 8.4.8. + +### Potential Issues + +- If you use publishable libraries, running `ng update @nrwl/schematics@8.4.8` will incorrectly update the version of `@angular/compiler-cli` and `@angular/language-service`. Update the versions manually before committing the changes. The issue is due to an incorrect peer dependency in `ng-packagr`, which we cannot fix in Nx. +- The schematics section of `angular.json` might still contain references to `@nrwl/schematics`. Update them to point to appropriate package (e.g., `@nrwl/angular`, `@nrwl/react`, `@nrwl/nest`). + +## Where you can find familiar features + +Below is a guide for users to find where the familiar features from Nx 7 can be found in Nx 8. + +### `create-nx-workspace` + +`create-nx-workspace` has not moved and remains in the `create-nx-workspace` package. + +### The Nx CLI + +The `nx` CLI has been moved to `@nrwl/workspace` which contains most of the core of Nx. It is still called `nx` so it can still be found at `./node_modules/.bin/nx`. + +#### `affected`, `format`, `lint`, `dep-graph` + +All CLI commands, `affected`, `format`, `lint`, and `dep-graph` have been moved to `@nrwl/workspace` as well. These commands are still run the same way via `yarn affected`, `yarn format`, etc.. + +### Jest Builder + +The builder for running Jest tests has been moved to `@nrwl/jest` which contains all of the Jest capabilities and can be specified as follows: + +- `@nrwl/builders:jest` is now `@nrwl/jest:jest` + +### Cypress Builder + +The builder for running Cypress tests has been moved `@nrwl/cypress` which contains all of the Cypress capabilities and can be specified as follows: + +- `@nrwl/builders:cypress` is now `@nrwl/cypress:cypress` + +### Angular + +#### Schematics + +All Angular schematics such as `app`, `lib`, `ngrx`, `downgrade-module`, and `upgrade-module` have been moved to `@nrwl/angular` which contains all of the Angular Capabilities. You can generate these same schematics by specifying `@nrwl/angular` as the collection. For example, use `ng g @nrwl/angular:app` to generate an Angular application. If `@nrwl/angular` is the default collection in the workspace, you can continue using `ng g app`. + +#### DataPersistence + +DataPersistence has been moved to `@nrwl/angular` as well and can be imported from `@nrwl/angular`. + +### React + +#### Schematics + +All React schematics such as `app` and `lib` have been moved to `@nrwl/react` which contains all of the React capabilities. You can generate these same schematics by specifying `@nrwl/react` as the collection. For example, use `ng g @nrwl/react:app` to generate a React application. If `@nrwl/react` is the default collection in the workspace, you can continue to use `ng g app`. + +#### Builders + +The builders for building and serving React apps has been moved to `@nrwl/web`. The React builder is no different from the one used to bundle normal web applications so `@nrwl/react` depends on that functionality from `@nrwl/web`. You do not need to add `@nrwl/web` yourself as adding `@nrwl/react` will add it's dependencies for you. + +### Web + +#### Schematics + +All Web schematics such as `app` and `lib` have been moved to `@nrwl/web` which contains all of the Web capabilities. You can generate these same schematics by specifying `@nrwl/web` as the collection. For example, use `ng g @nrwl/web:app` to generate a Web application. If `@nrwl/web` is the default collection in the workspace, you can continue to use `ng g app`. + +#### Builders + +The builders for building and serving Web apps has been moved to `@nrwl/web` and can be specified as follows: + +- `@nrwl/builders:web-build` is now `@nrwl/web:build` +- `@nrwl/builders:web-dev-server` is now `@nrwl/web:dev-server` + +### Nest + +#### Schematics + +All Nest schematics such as `app` have been moved to `@nrwl/nest` which contains all of the Nest capabilities. You can generate these same schematics by specifying `@nrwl/nest` as the collection. For example, use `ng g @nrwl/nest:app` to generate a Nest application. If `@nrwl/nest` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builders for building and serving Nest apps has been moved to `@nrwl/node`. The Nest builder is no different from the one used to bundle normal NodeJS applications so `@nrwl/nest` depends on that functionality from `@nrwl/node`. You do not need to add `@nrwl/node` yourself as adding `@nrwl/nest` will add it's dependencies for you. + +### Express + +#### Schematics + +All Express schematics such as `app` have been moved to `@nrwl/express` which contains all of the Express capabilities. You can generate these same schematics by specifying `@nrwl/express` as the collection. For example, use `ng g @nrwl/express:app` to generate an Express application. If `@nrwl/express` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builders for building and serving Express apps has been moved to `@nrwl/node`. The Express builder is no different from the one used to build normal NodeJS applications so `@nrwl/express` depends on that functionality from `@nrwl/node`. You do not need to add `@nrwl/node` yourself as adding `@nrwl/express` will add it's dependencies for you. + +### Node + +#### Schematics + +All Node schematics such as `app` have been moved to `@nrwl/node` which contains all of the Node capabilities. You can generate these same schematics by specifying `@nrwl/node` as the collection. For example, use `ng g @nrwl/node:app` to generate a Node application. If `@nrwl/node` is the default collection in the workspace, you can use `ng g app` instead of `ng g node-app`. + +#### Builders + +The builder for building and serving Node apps has been moved to `@nrwl/node` and can be specified as follows: + +- `@nrwl/builders:node-build` is now `@nrwl/node:build` +- `@nrwl/builders:node-execute` is now `@nrwl/node:execute` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/running-custom-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/running-custom-commands.md new file mode 100644 index 0000000000..d9bb335fa0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/running-custom-commands.md @@ -0,0 +1,58 @@ +# Running Custom Commands + +[Compodoc](https://compodoc.app/) is a great tool for automatically generating documentation for Angular projects. In order to use it, you need to run a simple command in the terminal. + +This recipe will show how to run any terminal command within the nx build-chain using Compodoc as an example. + +## Steps + +##### 1. Define the terminal command to be run + +The command we want to run for each project is: + +```bash +compodoc -p [path/to/tsconfig.json] +``` + +##### 2. Update `angular.json` + +For each project for which you want to enable compodoc, add a target in `angular.json`: + +```json +// ... +"my-app": { + "architect": { + "compodoc": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx compodoc -p apps/my-app/tsconfig.app.json" + } + ] + } + } + // ... + } +} +``` + +For more information, see the [run-commands api doc](/{{framework}}/workspace/run-commands-executor). + +Note: Replace `apps/my-app/tsconfig.app.json` with the appropriate `tsconfig.json` path for each project. + +##### 3. Trigger the builder from the terminal + +To run the builder for a single project: + +```bash +nx run my-app:compodoc +``` + +To run the builder for all affected projects: + +```bash +nx affected --target=compodoc +``` + +For more information, see the [nx affected](/{{framework}}/cli/affected). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/setup-incremental-builds.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/setup-incremental-builds.md new file mode 100644 index 0000000000..51fa77b63a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/setup-incremental-builds.md @@ -0,0 +1,109 @@ +# Setup incremental builds for Angular applications + +In this guide we’ll specifically look into which changes need to be made to enable [incremental builds](/angular/ci/incremental-builds) for Angular applications. + +## Use buildable libraries + +To enable incremental builds you need to use buildable libraries. +You can generate a new buildable lib with + +``` +nx g @nrwl/angular:lib mylib --buildable +``` + +## Adjust the executors/builders + +Nx comes with faster executors allowing for a faster build. Make sure that your libraries use the @nrwl/angular:ng-packagr-lite builder. + +``` +"mylib": { + "projectType": "library", + ... + "architect": { + "build": { + "builder": "@nrwl/angular:ng-packagr-lite", + "options": {...}, + "configurations": {...} + }, + "lint": {...}, + "test": {...} + }, + ... +}, +``` + +Change your Angular app’s executor to @nrwl/angular:webpack-browser and the “serve” executor to @nrwl/web:file-server instead. + +``` +"app0": { + "projectType": "application", + ... + "architect": { + "build": { + "builder": "@nrwl/angular:webpack-browser", + "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 commands. + +``` +nx build myapp --with-deps --parallel +``` + +To serve an app incrementally use this command: + +``` +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. + +``` +"app0": { + "projectType": "application", + ... + "architect": { + "build": { + "builder": "@nrwl/angular:webpack-browser", + "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/data-access-documents/src/data/11.4.0/angular/guides/storybook-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/storybook-plugin.md new file mode 100644 index 0000000000..3aeb8aef57 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/storybook-plugin.md @@ -0,0 +1,384 @@ +# Storybook + +![Storybook logo](/shared/storybook-logo.png) + +Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. + +## How to Use Storybook in an Nx Repo + +### Add the Storybook plugin + +```bash +yarn add --dev @nrwl/storybook +``` + +### Generating Storybook Configuration + +You can generate Storybook configuration for an individual project with this command: + +```bash +nx g @nrwl/angular:storybook-configuration project-name +``` + +If there's no `.storybook` folder at the root of the workspace, one is created. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── apps/ +├── libs/ +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +Also, a project-specific `.storybook` folder is added in the root of the project. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── src/ +├── README.md +├── tsconfig.json +└── etc... +``` + +### Running Storybook + +Serve Storybook using this command: + +```bash +nx run project-name:storybook +``` + +### Auto-generate Stories + +The `@nrwl/angular:storybook-configuration` generator has the option to automatically generate `*.stories.ts` files for each component declared in the library. + +```treeview +/ +├── my.component.ts +└── my.component.stories.ts +``` + +### Run Cypress Tests Against a Storybook Instance + +Both `storybook-configuration` generator gives the option to set up an e2e Cypress app that is configured to run against the project's Storybook instance. + +To launch Storybook and run the Cypress tests against the iframe inside of Storybook: + +```bash +nx run project-name-e2e:e2e +``` + +The url that Cypress points to should look like this: + +`'/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default'` + +- `buttoncomponent` is a lowercase version of the `Title` in the `*.stories.ts` file. +- `primary` is the name of an individual story. +- `knob-style=default` sets the `style` knob to a value of `default`. + +Changing knobs in the url query parameters allows your Cypress tests to test different configurations of your component. + +### Example Files + +**\*.component.stories.ts file** + +```typescript +import { text, number } from '@storybook/addon-knobs'; +import { ButtonComponent } from './button.component'; + +export default { + title: 'ButtonComponent', +}; + +export const primary = () => ({ + moduleMetadata: { + imports: [], + }, + component: ButtonComponent, + props: { + text: text('text', 'Click me!'), + padding: number('padding', 0), + style: text('style', 'default'), + }, +}); +``` + +**Cypress \*.spec.ts file** + +```typescript +describe('shared-ui', () => { + beforeEach(() => + cy.visit( + '/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default' + ) + ); + + it('should render the component', () => { + cy.get('storybook-trial-button').should('exist'); + }); +}); +``` + +### Using Addons + +To register an [addon](https://storybook.js.org/addons/) for all storybook instances in your workspace: + +1. In `/.storybook/main.js`, in the `addons` array of the `module.exports` object, add the new addon: + ``` + module.exports = { + stories: [...], + ..., + addons: [..., '@storybook/addon-knobs/register'], + }; + ``` +2. If a decorator is required, in each project's `/.storybook/preview.js` use the `addDecorator` function. + + ``` + import { configure, addDecorator } from '@storybook/angular'; + import { withKnobs } from '@storybook/addon-knobs'; + + addDecorator(withKnobs); + ``` + +**-- OR --** + +To register an [addon](https://storybook.js.org/addons/) for a single storybook instance, go to that project's `.storybook` folder: + +1. In `main.js`, in the `addons` array of the `module.exports` object, add the new addon: + ``` + module.exports = { + stories: [...], + ..., + addons: [..., '@storybook/addon-knobs/register'], + }; + ``` +2. If a decorator is required, in `preview.js` use the `addDecorator` function. + + ``` + import { configure, addDecorator } from '@storybook/angular'; + import { withKnobs } from '@storybook/addon-knobs'; + + addDecorator(withKnobs); + ``` + +### More Information + +For more on using Storybook, see the [official Storybook documentation](https://storybook.js.org/docs/basics/introduction/). + +## Upgrading to Storybook 6 (and Nx versions >10.1.x) + +Nx now comes with [Storybook version 6](https://storybook.js.org/releases/6.0). Chances are, if you used Nx version `10.1.x` or older with Storybook, you are using [Storybook version 5.3](https://storybook.js.org/releases/5.3) with configuration files of [Storybook version 5.2](https://storybook.js.org/releases/5.2). + +Nx version `10.2.x` will continue to support Storybook version `5.2.x`, however newer versions of Nx will only support Storybook version `6` (and on). + +When you are running the Nx workspace migration script, your Storybook instances and configurations across your apps and libraries will NOT be migrated automatically. We chose not to migrate your Storybook instances and configurations across your apps and libraries automatically, since there a number of breaking changes that Storybook introduced in versions `5.3` and `6.0`, and making decisions on what to migrate automatically would risk the integrity of your code. + +Instead, when you choose to migrate from Nx versions `<10.1.x` to Nx versions `>10.2.x` (using the Nx migration script - `nx migrate`) we will keep your Storybook packages and Storybook instances and configurations intact. We suggest that you do the migration on your own, using the guide below, with all the references to the official Storybook migration guides. Look at the use cases below, and follow the one that matches your case. + +### Use cases: + +#### Use case 1: Create an Nx workspace from scratch using the latest version of Nx + +If you are creating an Nx workspace using the latest version of Nx, the latest version of Storybook (version 6) will be used as well. You do not need to do anything. + +#### Use case 2: I already have an Nx workspace that does NOT use Storybook and I want to migrate to the latest Nx + +If you already have an Nx workspace with a previous version of Nx that does NOT use Storybook, and you migrate to the latest Nx using the migrate scripts provided by Nx, and then, after the migration to the latest Nx, you choose to add Storybook, the latest version of Storybook will be used. You do not need to do anything. + +#### Use case 3: I already have an Nx workspace with Storybook and I want to migrate to the latest Nx + +In that case, when you run the Nx migration scripts, the scripts will ignore the Storybook packages, the Storybook configuration files, the Storybook instances in your apps and libraries, and all the generated stories. If you continue to add Storybook configurations and Storybook instances to new libraries and applications, then the version of Storybook that you already have will be used (most probably, if you have not changed anything manually, that version will be `5.3.9` using, however, the configuration files of `5.2`). You will have to do the [upgrade to the latest Storybook on your own, manually](#upgrading-to-storybook-6-manually). After that, Nx will use that version, and configure all new Storybook instances using the new version. + +### Upgrading to Storybook 6 using the Nx migration generator + +#### Some info about the generator + +The `@nrwl/angular:storybook-migrate-defaults-5-to-6` generator will not exactly do a migration. It will perform the following actions: + +- It will generate new Storybook configuration files using the new (`>6.x`) Storybook way. The way it will do that is, it will look into `workspace.json` and it will find all the projects that have a `Storybook` configuration. Using the `configFolder` path provided there, it will go and generate new Storybook instaces in all these paths. Finally, it will generate a new Storybook instance at the root directory. + +- If you choose to `keepOld`, then it will add all your existing Storybook configuration files into another folder labeled `.old_storybook`. + +- It will update all the Storybook-related (`@storybook/*`) packages in your `package.json`. + +#### How to use the generator + +That way, you can have working Storybook instances for all your projects just by running + +``` +nx g @nrwl/angular:storybook-migrate-defaults-5-to-6 +``` + +#### What if I had made changes to the defaults? + +In case you had made customizations to the default Storybook configurations, you can then manually change each of your Storybook instance configuration files using the official [Storybook 6 Migration Guide](https://medium.com/storybookjs/storybook-6-migration-guide-200346241bb5) to make sure you use the new syntax. Your old configuration files are available to you to use as a reference. + +Please check out this official [Storybook 6 Migration Guide](https://medium.com/storybookjs/storybook-6-migration-guide-200346241bb5) article, as well as the [detailed guides here](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-53x-to-60x). + +#### What if I am not ready to change everything at once? + +The generator gives you the option to migrate one project at a time. You can provide the `--name=PROJECT_NAME` flag, and then the generator will **only** generate new files for the specified project. + +Please note that this option will NOT update all the Storybook-related (`@storybook/*`) packages in your `package.json`, or the root Storybook folder. The reason is that if you want to do the migration gradually, one project at a time, you want your old, existing, projects, to still work. That way, you will still be able to run your old, non-migrated Storybook projects. However, you will not be able to run any migrated Storbook projects. Once you have migrated all your Storybook projects, you can run `nx g @nrwl/angular:storybook-migrate-defaults-5-to-6` once again, and the generator will take care of updating all the Storybook-related (`@storybook/*`) packages in your `package.json` and it will also generate the new Storybook files for the root Storybook directory. + +#### General tip: + +**Commit any changes you have locally**. We would suggest that you start the migration with a clean git history, in case anything goes wrong. + +### Upgrading to Storybook 6 manually + +There is really no great reason for doing the migration completely manually. The `@nrwl/angular:storybook-migrate-defaults-5-to-6` generator [will take care of Steps 1, 2 and 3](#upgrading-to-storybook-6-using-the-nx-migration-generator). What you will need to do after running the generator is that you have to manually migrate any custom changes you had done to the default Storybook configuration files that were automatically generated by Nx when you first used Nx Storybook. To do the manual migration you should use the official [Storybook 6 Migration Guide](https://medium.com/storybookjs/storybook-6-migration-guide-200346241bb5) article, as well as the [detailed guides here](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-53x-to-60x). + +However, if you still want to do everything manually, these are the steps you should follow: + +#### Step 0: + +**Commit any changes you have locally**. We would suggest that you start the migration with a clean git history, in case anything goes wrong. + +#### Step 1: Changing the configuration files from version 5.2 to 5.3 + +The most noticeable change in Storybook versions newer than `5.2` is that the configuration files have changed names and content. +Quoting from the [official Storybook migration guide](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-52x-to-53x): + +- `presets.js` has been renamed to `main.js`. `main.js` is the main point of configuration for storybook. +- `config.js` has been renamed to `preview.js`. `preview.js` configures the "preview" iframe that renders your components. +- `addons.js` has been renamed to `manager.js`. `manager.js` configures Storybook's "manager" UI that wraps the preview, and also configures addons panel. + +Please follow the [official Storybook version 5.2.x to 5.3.x migration guide](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-52x-to-53x) to change your files accordingly. + +If you are using Storybook using only the generated files after running the `storybook-configuration` generator, things might be easier for you. Please check the [sample files for a manual upgrade](#sample-files-for-manual-upgrade). + +#### Step 2: Going from version 5.3 to 6.0 + +Please check out this official [Storybook 6 Migration Guide](https://medium.com/storybookjs/storybook-6-migration-guide-200346241bb5) article, as well as the [detailed guides here](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-53x-to-60x). + +- One big change in Storybook version `6` is that it has **built-in Typescript support**. This means that you can remove Typescript configurations from your configuration files. +- Please also **check that your stories match any differences in syntax** introduced in versions `5.3` and `6.0`. + +#### Step 3: Upgrade all `@storybook/*` packages in your project + +Check your `package.json` file for all `@storybook` packages. Install the latest versions of these, usign `yarn`: + +For example: + +``` +yarn add --dev @storybook/angular@latest +``` + +#### Step 4: Check that everything works as expected + +Check that everything works as expected. If you are still having trouble, you can submit you issue in the [GitHub Nx repo](https://github.com/nrwl/nx). We wish you luck! + +### Sample files for manual upgrade + +If you have not changed the content of the files which the `storybook-configuration` generator produced, you can use the following samples to migrate to Storybook `6`: + +#### Configuring the root `./storybook` directory + +- In the root `./storybook` directory, create a new file named `main.js` with the following content: + +``` +module.exports = { + stories: [], + addons: ['@storybook/addon-knobs/register'], +}; +``` + +- If you have any addons in the `addons.js` file, add them in the `addons` array in the `main.js` file. If you are using the default generated files without any changes, you should only have the `@storybook/addon-knobs/register` addon, which we already put in the array. You can now delete the `addons.js` file. + +- The other two files remain unchanged. + +#### Configuring the Storybook instances across apps and libraries - the library-specific `./storybook` directories + +- In the library `./storybook` directory, create a new file named `main.js` with the following content: + +``` +const lib_main_module = require('../../.storybook/main'); + +lib_main_module.stories.push('../src/lib/**/*.stories.mdx'); +lib_main_module.stories.push('../src/lib/**/*.stories.@(js|jsx|ts|tsx)'); +module.exports = lib_main_module; +``` + +Please take extra care making sure that the path to the root `./storybook` directory provided in the first line is correct. + +- If you have any addons in the `addons.js` file, add them in the `addons` array in the `main.js` file. You can add any addons in the `addons` module array using the following syntax: + +``` +lib_main_module.addons.push(''); +``` + +After you add any addons in the `main.js` file, you can safely delete the `addons.js` file. If you are using the default generated files without any changes, your `addons.js` file should be empty (but an import line, referencing the root `addons.js` file). + +- Rename the file `config.js` to `preview.js` and remove the last line where your stories paths are configured. Now, the contents of the `preview.js` file will look like this: + +``` +import { addDecorator } from '<%= uiFramework %>'; +import { withKnobs } from '@storybook/addon-knobs'; + +addDecorator(withKnobs); +``` + +- Modify the contents of `webpack.config.js`. Remove the following lines, which are the TypeScript configuration, which is not needed by Storybook any more: + +``` + config.resolve.extensions.push('.ts', '.tsx'); + config.module.rules.push({ + test: /\.(ts|tsx)$/, + loader: require.resolve('babel-loader'), + options: { + presets: [ + '@babel/preset-env', + '@babel/preset-react', + '@babel/preset-typescript' + ] + } + }); +``` + +#### Check final folder structure + +Your folder structure should now look like this: + +``` +/ +├── .storybook/ +│ ├── main.js +│ ├── tsconfig.json +│ └── webpack.config.js +├── apps/ +├── libs/ +│ └── / +│ ├── .storybook/ +│ │ ├── main.js +│ │ ├── tsconfig.json +│ │ └── webpack.config.js +│ ├── src/ +│ ├── README.md +│ ├── tsconfig.json +│ └── etc... +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +### Storybook v6 args and controls + +Storybook v6 moves from "knobs" to args and controls when it comes to defining and manipulating your storybook +component properties. Feel free to use the new args way of defining stories. More can be found +[on the official Storybook docs](https://storybook.js.org/docs/angular/writing-stories/args). + +> **Note:** Nx does not yet automatically generate stories that use the args syntax. The main reason is that args don't +> yet support being loaded via the iframe URL which is used in Nx to setup your Storybook based e2e tests. Once support +> is present in Storybook v6, we will provide a way to generate args & controls based stories. More on the progress [here](https://github.com/storybookjs/storybook/issues/12291). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/update.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/update.md new file mode 100644 index 0000000000..e7d4197503 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/guides/update.md @@ -0,0 +1,138 @@ +# Updating Nx + +Nx provides the `migrate` command which help you stay up to date with the latest version of Nx. + +Not only `nx migrate` updates the version of Nx, but it also updates the versions of dependencies which we install such as jest and cypress. You can also use the `migrate` command to update any Nx plugin or any Angular package. + +## What About "Ng Update?" + +**TLDR: So if you are using Nx 10, run `nx migrate latest` instead of `ng update`.** + +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 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 4 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 ran `ng update` and saw the error telling you to use `nx migrate`, do the following: + +- `git checkout .` +- `git clean -f .` +- `rm -rf node_modules` +- `npm install` (or `yarn install`) +- `nx migrate latest` +- `npm install` (or `yarn install`) +- `nx migrate --run-migrations=migrations.json` + +## How to Migrate + +Migration happens in two steps: + +- Updating `package.json` (and `node_modules`) +- Updating the source code of the repo to match the new versions of packages in `package.json` + +### Step 1: Updating package.json and generating migrations.json + +Run the following: + +```bash +nx migrate latest # same as nx migrate @nrwl/workspace@latest +``` + +You can also specify the name of the package and the version: + +```bash +nx migrate @nrwl/workspace@version # you can also specify version +``` + +This will fetch the specified version of `@nrwl/workspace`, analyze the dependencies and fetch all the dependent packages. The process will keep going until the whole tree of dependencies is resolved. This will result in: + +- `package.json` being updated +- `migrations.json` being generated + +At this point, no packages have been installed, and no other files have been touched. + +Now, you can inspect `package.json` to see if the changes make sense. Sometimes the migration can update some package to the version that is either not allowed or conflicts with with another package. After you are satisfied, run `npm install`, `yarn`, or `pnpm install`. + +### Step 2: Running migrations + +Next, we need to update the repo to match the updated `package.json` and `node_modules`. Every Nx plugin comes with a set of migrations that describe how to update the workspace to make it work with the new version of the plugin. During Step 1 Nx looked at all of the packages being updated and collected their migrations into `migrations.json`. It's important to note that because Nx knows the from and to versions of every package, the `migrations.json` file only contains the relevant migrations. + +Each migration in `migrations.json` updates the source code in the repository. To run all the migrations in order, invoke: + +```bash +nx migrate --run-migrations=migrations.json +``` + +For small projects, running all the migrations at once often succeeds without any issues. For large projects, more flexibility is sometimes needed: + +- You may have to skip a migration. +- You may want to run one migration at a time to address minor issues. +- You may want to reorder migrations. +- You may want to run the same migration multiple time if the process takes a long time and you had to rebase. + +Since you can run `nx migrate --run-migrations=migrations.json` as many times as you want, you can achieve all of that by commenting out and reordering items in `migrations.json`. The migrate process can take a long time, sometimes a day, so it can be useful to commit the migrations file with the partially-updated repo. + +### Step 3: Cleaning up + +After you run all the migrations, you can remove `migration.json` and commit the changes. + +## Advanced Capabilities & Recommendations + +### One Major Version at a Time, Small Steps + +Migrating Jest, Cypress, ESLint, React, Angular, Next etc... is a difficult task. All the tools change at different rates, they can conflict with each other etc.. In addition, every workspace is different. Even though our goal is to let you update any version of Nx to any other version in a single go, sometimes it doesn't work. The following process is better for large workspaces. + +Say you want to migrate from Nx 10.1.0 to Nx 11.0.1. The following steps are more likely to work comparing to `nx migrate 11.0.1`. + +- Run `nx migrate 10.4.5` to update the latest version in the 10x branch. +- Run `npm install` +- Run `nx migrate --run-migrations=migrations.json` +- Next, run `nx migrate 11.0.1` +- Run `npm install` +- Run `nx migrate --run-migrations=migrations.json` + +### Overriding versions + +Sometimes, you may want to use a different version of a package than what Nx recommends. You can do it as follows: + +```bash +nx migrate @nrwl/workspace --to="jest@22.0.0,cypress:3.4.0" +``` + +By default, Nx uses currently installed packages to calculate what migrations need to run. You can override them like this: + +```bash +nx migrate @nrwl/workspace --to="@nrwl/jest@8.0.0" +``` + +### Reverting a failed update + +Updates are best done on a clean git history so that it can be easily reversed if something fails. +We try our best to make sure migrations do not fail but if one does, **please report it** on [Github](https://www.github.com/nrwl/nx/issues/new/). +If an update fails for any reason, you can revert it as you do any other set of changes: + +```bash +git reset --hard # Reset any changes +git clean -fd # Delete newly added files and directories +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angular.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angular.md new file mode 100644 index 0000000000..f0a7fd7b30 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angular.md @@ -0,0 +1,379 @@ +# Transitioning to Nx + +Within an Nx workspace, you gain many capabilities that help you build applications and libraries +using a monorepo approach. If you are currently using an Angular CLI workspace, you can transform it into an Nx workspace. + +## Prerequisites + +- The major version of your `Angular CLI` must align with the version of `Nx` you are upgrading to. For example, if you're using Angular CLI version 7, you must transition using the latest version 7 release of Nx. +- Currently, transforming an Angular CLI workspace to an Nx workspace automatically only supports a single project. If you have more than one project in your Angular CLI workspace, you can still migrate manually. + +## Using ng add and preserving your existing structure + +To add Nx to an existing Angular CLI workspace to an Nx workspace, with keeping your existing file structure in place, use the `ng add` command with the `--preserveAngularCLILayout` option: + +``` +ng add @nrwl/workspace --preserveAngularCLILayout +``` + +This installs the `@nrwl/workspace` package into your workspace and applies the following changes to your workspace: + +- Adds and installs the `@nrwl/workspace` package in your development dependencies. +- Creates an nx.json file in the root of your workspace. +- Adds a `decorate-angular-cli.js` to the root of your workspace, and a `postinstall` script in your `package.json` to run the script when your dependencies are updated. The script forwards the `ng` commands to the Nx CLI(nx) to enable features such as Computation Caching. + +After the process completes, you continue using the same serve/build/lint/test commands. + +## Using ng add + +To transform a Angular CLI workspace to an Nx workspace, use the `ng add` command: + +``` +ng add @nrwl/workspace +``` + +This installs the `@nrwl/workspace` package into your workspace and runs a generator (or schematic) to transform your workspace. The generator applies the following changes to your workspace: + +- Installs the packages for the `Nx` plugin `@nrwl/angular` in your package.json. +- Creates an nx.json file in the root of your workspace. +- Creates configuration files for Prettier. +- Creates an `apps` folder for generating applications. +- Creates a `libs` folder for generating libraries. +- Creates a `tools` folder that includes files for custom workspace tooling, such as workspace-specific generators and scripts. +- Moves your application into the `apps` folder, and updates the relevant file paths in your configuration files. +- Moves your e2e suite into the `apps/{{app name}}-e2e` folder, and updates the relevant file paths in your configuration files. +- Updates your `package.json` with scripts to run various `Nx` workspace commands. +- Updates your `angular.json` configuration to reflect the new paths. + +After the changes are applied, your workspace file structure should look similar to below: + +```treeview +/ +├── apps/ +│   ├── / +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.css +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── karma.conf.js +│   │   ├── tsconfig.app.json +│   │   └── tsconfig.spec.json +│   └── -e2e/ +│      ├── src/ +│      ├── protractor.conf.js +│      └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── angular.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Your workspace is now powered by Nx! You can verify out that your application still runs as intended: + +- To serve, run `ng serve`. +- To build, run `ng build`. +- To run unit tests, run `ng test`. +- To run e2e tests, run `ng e2e`. +- To see your dependency graph, run `nx dep-graph`. + +> Your dependency graph will grow as you add, and use more applications and libraries. + +Learn more about the advantages of Nx in the following guides: + +- [Using Cypress for e2e tests](/angular/cypress/overview) +- [Using Jest for unit tests](/angular/jest/overview) +- [Computation Caching](/angular/core-concepts/computation-caching) +- [Rebuilding and Retesting What is Affected](/angular/core-concepts/affected) + +## Transitioning Manually + +If you are unable to automatically transform your Angular CLI workspace to an Nx workspace using the [ng add](angular/migration/migration-angular#using-ng-add) method, there are some manual steps you can take to move your project(s) into an Nx workspace. + +### Generating a new workspace + +To start, run the command to generate an Nx workspace with an Angular application. + +**Using `npx`** + +```bash +npx create-nx-workspace myorg --preset=angular +``` + +**Using `npm init`** + +```bash +npm init nx-workspace myorg --preset=angular +``` + +**Using `yarn create`** + +```bash +yarn create nx-workspace myorg --preset=angular +``` + +When prompted for the `application name`, enter the _project name_ from your current `angular.json` file. + +A new Nx workspace with your `org name` as the folder name, and your `application name` as the first application is generated. + +```treeview +/ +├── apps/ +│   ├── / +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.css +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tslint.json +│   │   └── tsconfig.spec.json +│   └── -e2e/ +│      ├── src/ +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tslint.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── .prettierignore +├── .prettierrc +├── README.md +├── angular.json +├── jest.config.js +├── nx.json +├── package.json +├── tsconfig.json +└── tslint.json +``` + +### Copying over application files + +Your application code is self-contained within the `src` folder of your Angular CLI workspace. + +- Copy the `src` folder from your Angular CLI project to the `apps/` folder, overwriting the existing `src` folder. +- Copy any project-specific files, such as `browserslist`, or service worker configuration files into their relative path under the `apps/` folder. +- Transfer the `assets`, `scripts`, `styles`, and build-specific configuration, such as service worker configuration, from your Angular CLI `angular.json` to the Nx workspace `angular.json` file. + +Verify your app runs correctly by running: + +```sh +ng serve +``` + +### Updating your unit testing configuration + +Nx uses Jest by default. If you have any custom Jest configuration, you need to update the workspace Jest configuration also. + +Verify your tests run correctly by running: + +```sh +ng test +``` + +If you are using `Karma` for unit testing: + +- Copy the `karma.conf.js` file to your `apps/` folder. +- Copy the `test.ts` file to your `apps//src` folder. +- Copy the `test` target in your `architect` configuration from your Angular CLI `angular.json` file into your Nx workspace `angular.json` file. +- Update your `test` target to prepend `apps/` to each of the file paths. + +```json +{ + "projects": { + "": { + "projectType": "application", + "schematics": {}, + "root": "apps/", + "sourceRoot": "apps//src", + "prefix": "myapp", + "architect": { + "test": { + "builder": "@angular-devkit/build-angular:karma", + "options": { + "main": "apps//src/test.ts", + "polyfills": "apps//src/polyfills.ts", + "tsConfig": "apps//tsconfig.spec.json", + "karmaConfig": "apps//karma.conf.js", + "assets": [ + "apps//src/favicon.ico", + "apps//src/assets" + ], + "styles": ["apps//src/styles.css"], + "scripts": [] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/angular" + }, + "schematics": { + "@nrwl/angular:application": { + "unitTestRunner": "jest", + "e2eTestRunner": "cypress" + }, + "@nrwl/angular:library": { + "unitTestRunner": "jest" + } + }, + "defaultProject": "" +} +``` + +> Jest will be used by default when generating new applications. If you want to continue using `Karma`, set the `unitTestRunner` to `karma` in the `schematics` section of the `angular.json` file. + +- Update `test-setup.ts` to `test.ts` in the `files` array of the `apps//tsconfig.spec.json` file. + +```json +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../dist/out-tsc", + "module": "commonjs", + "types": ["node"] + }, + "files": ["src/test.ts", "src/polyfills.ts"], + "include": ["**/*.spec.ts", "**/*.d.ts"] +} +``` + +Verify your tests run correctly by running: + +```sh +ng test +``` + +### Updating your E2E testing configuration + +Nx uses Cypress by default. If you are already using Cypress, copy your E2E setup files into the `apps/-e2e` folder and verify your tests still run correctly by running: + +```sh +ng e2e -e2e +``` + +If you are using `Protractor` for E2E testing: + +- Delete the `apps/-e2e` folder that was generated to use Cypress. +- Copy the `e2e` folder from your Angular CLI workspace into the `apps` file to your `apps/` folder. +- Rename the `e2e` folder to `-e2e`. +- In the Nx workspace `angular.json`, update your `-e2e` project with the `Protractor` configuration. + +```json +{ + "version": 1, + "projects": { + "-e2e": { + "root": "apps/-e2e", + "projectType": "application", + "architect": { + "e2e": { + "builder": "@angular-devkit/build-angular:protractor", + "options": { + "protractorConfig": "apps/-e2e/protractor.conf.js", + "devServerTarget": ":serve" + }, + "configurations": { + "production": { + "devServerTarget": ":serve:production" + } + } + }, + "lint": { + "builder": "@angular-devkit/build-angular:tslint", + "options": { + "tsConfig": "apps/-e2e/tsconfig.e2e.json", + "exclude": ["**/node_modules/**", "!apps/-e2e/**/*"] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/angular" + }, + "schematics": { + "@nrwl/angular:application": { + "unitTestRunner": "jest", + "e2eTestRunner": "cypress" + }, + "@nrwl/angular:library": { + "unitTestRunner": "jest" + } + }, + "defaultProject": "" +} +``` + +Create a `tsconfig.e2e.json` file under `apps/-e2e` folder: + +```json +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../dist/out-tsc" + } +} +``` + +Update the `apps//tsconfig.json` to extend the root `tsconfig.json`: + +```json +{ + "extends": "../../tsconfig.json", + "compilerOptions": { + "outDir": "../../out-tsc/-e2e", + "module": "commonjs", + "target": "es5", + "types": ["jasmine", "jasminewd2", "node"] + } +} +``` + +Verify your E2E tests run correctly by running: + +```sh +ng e2e -e2e +``` + +> Cypress will be used by default when generating new applications. If you want to continue using `Protractor`, set the `e2eTestRunner` to `protractor` in the `schematics` section of the `angular.json` file. + +### Updating your linting configuration + +For lint rules, migrate your existing rules into the root `tslint.json` file. + +Verify your lint checks run correctly by running: + +```sh +npm run lint +``` + +OR + +```sh +yarn lint +``` + +Learn more about the advantages of Nx in the following guides: + +[Using Cypress for e2e tests](/angular/cypress/overview) \ +[Using Jest for unit tests](/angular/jest/overview) \ +[Rebuilding and Retesting What is Affected](/angular/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs-unit-tests-passing.png b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs-unit-tests-passing.png new file mode 100644 index 0000000000..53414ab08c Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs-unit-tests-passing.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs.md new file mode 100644 index 0000000000..245223143c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/migration/migration-angularjs.md @@ -0,0 +1,684 @@ +# Migrating an AngularJS Project into an Nx Workspace + +Nx offers first-class support for Angular and React out-of-the-box. But one of the questions the Nrwl team often hears from our community is how to use AngularJS (Angular 1.x) in Nx. Nx is a great choice for managing an AngularJS to Angular upgrade, or just for consolidating your existing polyrepo approach to AngularJS into a monorepo to make maintenance a little easier. + +In this article, you’ll learn how to: + +- Create an Nx workspace for an AngularJS application +- Migrate an AngularJS application into your Nx workspace +- Convert an existing build process for use in Nx +- Use Webpack to build an AngularJS application +- Run unit and end-to-end tests + +For this example, you’ll be migrating the [Real World AngularJS](https://github.com/gothinkster/angularjs-realworld-example-app) application from [Thinkster.io](https://thinkster.io/). You should clone this repo so you have access to the code before beginning. + +There is also a [repo](https://github.com/nrwl/nx-migrate-angularjs-example) that shows a completed example of this guide. + +> The RealWorld app is a great example of an AngularJS app, but it probably doesn’t have the complexity of your own codebase. As you go along, I’ll include some recommendations on how you might apply this example to your larger, more complex application. + +## Creating your workspace + +To start migrating the Real World app, create an Nx workspace: + +```bash +npx create-nx-workspace@latest nx-migrate-angularjs +``` + +When prompted choose the `empty` preset. The other presets use certain recommended defaults for the workspace configuration. Because you have existing code with specific requirements for configuration, starting with a blank workspace avoids resetting these defaults. This will give you the ability to customize the workspace for the incoming code. + +At the next prompt, choose `Angular CLI` for your workspace CLI. While you may not be using Angular now, this gives you the best option to upgrade to Angular later. The Angular CLI is also the best CLI option for using Karma and Protractor, the two testing suites most commonly used for AngularJS. + +```bash +? What to create in the new workspace empty [an empty workspace] +? CLI to power the Nx workspace Angular CLI [Extensible CLI for Angular applications. Recommended for Angular projects.] +``` + +## Creating your app + +Your new workspace won’t have much in it because of the `empty` preset. You’ll need to generate an application to have some structure created. Add the Angular capability to your workspace: + +```bash +ng add @nrwl/angular +``` + +When prompted, make a choice of unit test runner and e2e test runner: + +```bash +? Which Unit Test Runner would you like to use for the application? Karma [ https://karma-runner.github.io ] +? Which E2E Test Runner would you like to use? Protractor [ https://www.protractortest.org ] +``` + +For this example, we will use Karma and Protractor, the most common unit test runner and e2e test runner for AngularJS. + +> Codebases with existing unit and e2e tests should continue to use whatever runner they need. We’ve chosen Karma and Protractor here because it’s the most common. If you’re going to be adding unit testing or e2e as part of this transition and are starting fresh, we recommend starting with Jest and Cypress. + +With the Angular capability added, generate your application: + +```bash +ng generate @nrwl/angular:application --name=realworld +``` + +Accept the default options for each prompt: + +```bash +? Which stylesheet format would you like to use? CSS +? Would you like to configure routing for this application? No +``` + +> The RealWorld app doesn’t have any styles to actually bundle here. They’re all downloaded from a CDN that all of the RealWorld apps use. If your codebase uses something other than CSS, like Sass or PostCSS, you can choose that here. + +## Migrating dependencies + +Copy the dependencies from the RealWorld app’s `package.json` to the `package.json` in your workspace. Split the existing dependencies into `dependencies` (application libraries) and `devDependencies` (build and test libraries). Everything related to gulp can go into `devDependencies`. + +Your `package.json` should now look like this: + +```json +{ + "name": "nx-migrate-angularjs", + "version": "0.0.0", + "license": "MIT", + "scripts": { + "ng": "ng", + "nx": "nx", + "start": "ng serve", + "build": "ng build", + "test": "ng test", + "lint": "nx workspace-lint && ng lint", + "e2e": "ng e2e", + "affected:apps": "nx affected:apps", + "affected:libs": "nx affected:libs", + "affected:build": "nx affected:build", + "affected:e2e": "nx affected:e2e", + "affected:test": "nx affected:test", + "affected:lint": "nx affected:lint", + "affected:dep-graph": "nx affected:dep-graph", + "affected": "nx affected", + "format": "nx format:write", + "format:write": "nx format:write", + "format:check": "nx format:check", + "update": "ng update @nrwl/workspace", + "workspace-generator": "nx workspace-generator", + "dep-graph": "nx dep-graph", + "help": "nx help", + "postinstall": "ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points" + }, + "private": true, + "dependencies": { + "@nrwl/angular": "^9.0.4", + "@angular/animations": "9.0.0", + "@angular/common": "9.0.0", + "@angular/compiler": "9.0.0", + "@angular/core": "9.0.0", + "@angular/forms": "9.0.0", + "@angular/platform-browser": "9.0.0", + "@angular/platform-browser-dynamic": "9.0.0", + "@angular/router": "9.0.0", + "angular": "^1.5.0-rc.2", + "angular-ui-router": "^0.4.2", + "core-js": "^2.5.4", + "rxjs": "~6.5.0", + "zone.js": "^0.10.2" + }, + "devDependencies": { + "@angular/cli": "9.0.1", + "@nrwl/workspace": "9.0.4", + "@types/node": "~8.9.4", + "dotenv": "6.2.0", + "ts-node": "~7.0.0", + "tslint": "~5.11.0", + "eslint": "6.1.0", + "typescript": "~3.7.4", + "prettier": "1.18.2", + "@angular/compiler-cli": "9.0.0", + "@angular/language-service": "9.0.0", + "@angular-devkit/build-angular": "0.900.1", + "codelyzer": "~5.0.1", + "karma": "~4.0.0", + "karma-chrome-launcher": "~2.2.0", + "karma-coverage-istanbul-reporter": "~2.0.1", + "karma-jasmine": "~1.1.2", + "karma-jasmine-html-reporter": "^0.2.2", + "jasmine-core": "~2.99.1", + "jasmine-spec-reporter": "~4.2.1", + "@types/jasmine": "~2.8.8", + "protractor": "~5.4.0", + "@types/jasminewd2": "~2.0.3", + "babel-preset-es2015": "^6.3.13", + "babelify": "^7.2.0", + "browser-sync": "^2.11.1", + "browserify": "^13.0.0", + "browserify-ngannotate": "^2.0.0", + "gulp": "^3.9.1", + "gulp-angular-templatecache": "^1.8.0", + "gulp-notify": "^2.2.0", + "gulp-rename": "^1.2.2", + "gulp-uglify": "^1.5.3", + "gulp-util": "^3.0.7", + "marked": "^0.3.5", + "merge-stream": "^1.0.0", + "vinyl-source-stream": "^1.1.0" + } +} +``` + +Run `npm install` to install all of your new dependencies. + +> For your own project, you’ll need to switch to NPM if you’re using another package manager like bower. [Learn more about switching away from bower](https://bower.io/blog/2017/how-to-migrate-away-from-bower/) + +## Migrating application code + +This Angular application that you generated has the configuration that you need, but you don’t need any of its application code. You’ll replace that with the RealWorld app code. Delete the contents of `apps/realworld/src/app`. + +Starting in the `js` folder of the realworld app, copy all of the application code into `apps/realworld/src/app`. The resulting file tree should look like this: + +```text +apps +|____realworld-e2e +|____realworld +| |____src +| | |____index.html +| | |____app +| | | |____settings +| | | |____home +| | | |____config +| | | |____auth +| | | |____layout +| | | |____components +| | | |____profile +| | | |____article +| | | |____services +| | | |____editor +| | | |____app.js\ +| | |____styles.css +| | |____environments +| | |____main.ts +| | |____test.ts +| | |____assets +``` + +> You most likely have your own AngularJS project written in JavaScript as well. While you’ll continue to use JavaScript through the rest of this example, we strongly recommend switching AngularJS projects to TypeScript, especially if you’re planning an upgrade to Angular. + +## Modifying index.html and main.ts + +Your generated application will also have an `index.html` provided. However, it’s set up for an Angular application, not an AngularJS application. Replace the contents of `apps/realworld/src/index.html` with the `index.html` from the RealWorld app. + +Your application also has a `main.ts` file which is responsible for bootstrapping your app. Again, you don’t need much from this file any more. Replace its contents with: + +```typescript +import ‘./app/app.js’; +``` + +And re-name it to `main.js`. This will import the existing app.js file from the RealWorld app which will bootstrap the app. + +## Adding existing build and serve processes + +If you’re looking at the example repo, the code for this section is available on branch `initial-migration`. This section is an interim step that continues to use gulp to build and serve the app locally. You’ll replace gulp in the next section. The RealWorld app uses gulp 3.9.1 to build. This version is not supported anymore and doesn’t run on any version of Node greater than 10.\*. To build this using gulp, you need to install an appropriate version of Node and make sure you re-install your dependencies. If this isn’t possible (or you just don’t want to), feel free to skip to the next section. The webpack build process should run in any modern Node version. + +The RealWorld app uses gulp to build the application, as well as provide a development server. To verify that the migration has worked, stay with that build process for now. + +> During migration, you should take a small step and confirm that things work before moving ahead. Stopping and checking to see that your app still builds and functions is essential to a successful migration. + +Copy the `gulpfile.js` over from the RealWorld app and put it in `apps/realworld`. This is where all configuration files reside for the application. Make some adjustments to this file so that your build artifacts land in a different place. In an Nx workspace, all build artifacts should be sent to an app-specific folder in the `dist` folder at the root of your workspace. Your `gulpfile.js` should look like this: + +```javascript +var gulp = require('gulp'); +var notify = require('gulp-notify'); +var source = require('vinyl-source-stream'); +var browserify = require('browserify'); +var babelify = require('babelify'); +var ngAnnotate = require('browserify-ngannotate'); +var browserSync = require('browser-sync').create(); +var rename = require('gulp-rename'); +var templateCache = require('gulp-angular-templatecache'); +var uglify = require('gulp-uglify'); +var merge = require('merge-stream'); + +// Where our files are located +var jsFiles = 'src/app/**/*.js'; +var viewFiles = 'src/app/**/*.html'; + +var interceptErrors = function (error) { + var args = Array.prototype.slice.call(arguments); + + // Send error to notification center with gulp-notify + notify + .onError({ + title: 'Compile Error', + message: '<%= error.message %>', + }) + .apply(this, args); + + // Keep gulp from hanging on this task + this.emit('end'); +}; + +gulp.task('browserify', ['views'], function () { + return ( + browserify('./src/main.js') + .transform(babelify, { presets: ['es2015'] }) + .transform(ngAnnotate) + .bundle() + .on('error', interceptErrors) + //Pass desired output filename to vinyl-source-stream + .pipe(source('main.js')) + // Start piping stream to tasks! + .pipe(gulp.dest('../../dist/apps/realworld/')) + ); +}); + +gulp.task('html', function () { + return gulp + .src('src/index.html') + .on('error', interceptErrors) + .pipe(gulp.dest('../../dist/apps/realworld/')); +}); + +gulp.task('views', function () { + return gulp + .src(viewFiles) + .pipe( + templateCache({ + standalone: true, + }) + ) + .on('error', interceptErrors) + .pipe(rename('app.templates.js')) + .pipe(gulp.dest('src/app/config')); +}); + +// This task is used for building production ready +// minified JS/CSS files into the dist/ folder +gulp.task('build', ['html', 'browserify'], function () { + var html = gulp + .src('../../dist/apps/realworld/index.html') + .pipe(gulp.dest('../../dist/apps/realworld/')); + + var js = gulp + .src('../../dist/apps/realworld/main.js') + .pipe(uglify()) + .pipe(gulp.dest('../../dist/apps/realworld/')); + + return merge(html, js); +}); + +gulp.task('default', ['html', 'browserify'], function () { + browserSync.init(['../../dist/apps/realworld/**/**.**'], { + server: '../../dist/apps/realworld', + port: 4000, + notify: false, + ui: { + port: 4001, + }, + }); + + gulp.watch('src/index.html', ['html']); + gulp.watch(viewFiles, ['views']); + gulp.watch(jsFiles, ['browserify']); +}); +``` + +You need to point your `build` and `serve` tasks at this gulp build process. Typically, an Angular app is built using the Angular CLI, but the Angular CLI doesn’t know how to build AngularJS projects. All of your tasks are configured in the `angular.json` file. Find the `build` and `serve` tasks and replace them with this code block: + +```json +... + "build": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx gulp --gulpfile apps/realworld/gulpfile.js build" + } + ] + } + }, + "serve": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "npx gulp --gulpfile apps/realworld/gulpfile.js" + } + ] + } + }, +... +``` + +This sets up the `build` and `serve` commands to use the locally installed version of gulp to run `build` and `serve`. To see the RealWorld app working, run + +```bash +ng serve realworld +``` + +Navigate around the application and see that things work. + +> Your own project might not be using gulp. If you’re using webpack, you can follow the next section and substitute your own webpack configuration. If you’re using something else like grunt or a home-grown solution, you can follow the same steps here to use it. You’ll use the `run-commands` builder and substitute in the commands for your project. + +## Switching to webpack + +So far, you’ve mostly gotten already existing code and processes to work. This is the best way to get started with any migration: get existing code to work before you start making changes. This gives you a good, stable base to build on. It also means you having working code now rather than hoping you’ll have working code in the future! + +But migrating AngularJS code means we need to switch some of our tools to a more modern tool stack. Specifically, using webpack and babel is going to allow us to take advantage of Nx more easily. Becoming an expert in these build tools is outside the scope of this article, but I’ll address some AngularJS specific concerns. To get started, install a new dependency: + +```bash +npm install babel-plugin-angularjs-annotate +``` + +Nx already has most of what you need for webpack added as a dependency. `babel-plugin-angularjs-annotate` is going to accomplish the same thing that `browserify-ngannotate` previously did in gulp: add dependency injection annotations. + +Start with a `webpack.config.js` file in your application’s root directory: + +```javascript +const path = require('path'); + +module.exports = (config, context) => { + return { + ...config, + module: { + strictExportPresence: true, + rules: [ + { + test: /\.html$/, + use: [{ loader: 'raw-loader' }], + }, + // Load js files through Babel + { + test: /\.(js|jsx)$/, + loader: 'babel-loader', + options: { + presets: ['@babel/preset-env'], + plugins: ['angularjs-annotate'], + }, + }, + ], + }, + }; +}; +``` + +> This webpack configuration is deliberately simplified for this tutorial. A real production-ready webpack config for your project will be much more involved. See [this project](https://github.com/preboot/angularjs-webpack) for an example. + +To use webpack instead of gulp, go back to your `angular.json` file and modify the `build` and `serve` commands again: + +```json +... +"build": { + "builder": "@nrwl/web:build", + "options": { + "outputPath": "dist/apps/realworld", + "index": "apps/realworld/src/index.html", + "main": "apps/realworld/src/main.ts", + "polyfills": "apps/realworld/src/polyfills.ts", + "tsConfig": "apps/realworld/tsconfig.app.json", + "assets": [ + "apps/realworld/src/favicon.ico", + "apps/realworld/src/assets" + ], + "styles": ["apps/realworld/src/styles.css"], + "scripts": [], + "webpackConfig": "apps/realworld/webpack.config", + "buildLibsFromSource": true + }, + "configurations": { + "production": { + "fileReplacements": [ + { + "replace": "apps/realworld/src/environments/environment.ts", + "with": "apps/realworld/src/environments/environment.prod.ts" + } + ], + "optimization": true, + "outputHashing": "all", + "sourceMap": false, + "extractCss": true, + "namedChunks": false, + "extractLicenses": true, + "vendorChunk": false, + "budgets": [ + { + "type": "initial", + "maximumWarning": "2mb", + "maximumError": "5mb" + } + ] + } + } +}, +"serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "realworld:build" + } +}, +... +``` + +You may have noticed a rule for loading HTML in `webpack.config.js`. You need to modify some of your AngularJS code to load HTML differently. The application previously used the template cache to store all of the component templates in code, rather than download them at run time. This works, but you can do things a little better with webpack. + +Rather than assigning `templateUrl` for your components, you can instead import the HTML and assign it to the `template` attribute. This is effectively the same as writing your templates in-line, but you still have the benefit of having a separate HTML file. The advantage is that the template is tied to its component, not a global module like the template cache. Loading all templates into the template cache is more performant than individually downloading templates, but it also means your user is downloading every single component’s template as part of start-up. This was fine in AngularJS when you didn’t easily have access to lazy-loading, so you always had a large up-front download cost. As you begin to upgrade to Angular or other modern frontend frameworks, you will gain access to lazy-loading: only loading code when it’s necessary. By making this change now, you set yourself up for success later. + +To accomplish this, open `config/app.config.js` which is the main app component. Modify it like this: + +```javascript +import authInterceptor from './auth.interceptor'; +import template from '../layout/app-view.html'; + +function AppConfig( + $httpProvider, + $stateProvider, + $locationProvider, + $urlRouterProvider +) { + 'ngInject'; + + $httpProvider.interceptors.push(authInterceptor); + + /* + If you don't want hashbang routing, uncomment this line. + Our tutorial will be using hashbang routing though :) + */ + // $locationProvider.html5Mode(true); + + $stateProvider.state('app', { + abstract: true, + template, + resolve: { + auth: function (User) { + return User.verifyAuth(); + }, + }, + }); + + $urlRouterProvider.otherwise('/'); +} + +export default AppConfig; +``` + +This change loads the HTML code directly and sets it to the template attribute of the component. The HTML rule that you specified in the webpack config will take care of loading the HTML correctly and adding it to the template like this. + +Now, go through each component of the application and make this change. To make sure that you’ve really modified every component correctly, delete the template cache file (`config/app.templates.js`) that gulp generated earlier. + +> In an example like this, it’s easy enough to make this kind of change by hand. In a larger codebase, doing this manually could be very time-intensive. You’ll want to look into an automated tool to do this for you, such as js-codemod or generators. + +Run the application the same way as before: + +```bash +ng serve realworld +``` + +## Unit testing + +Unit testing can be an important part of any code migration. If you migrate your code into a new system, and all of your unit tests pass, you have a higher degree of confidence that your application actually works without manually testing. Unfortunately, the RealWorld application doesn’t have any unit tests, but you can add your own. + +You need a few dependencies for AngularJS unit testing that Nx doesn’t provide by default: + +```bash +npm install angular-mocks@1.5.11 karma-webpack +``` + +Earlier, you configured this app to use Karma as its unit test runner. Nx has provided a Karma config file for you, but you’ll need to modify it to work with AngularJS: + +```javascript +const webpack = require('./webpack.config'); +const getBaseKarmaConfig = require('../../karma.conf'); + +module.exports = function (config) { + const baseConfig = getBaseKarmaConfig(); + config.set({ + ...baseConfig, + frameworks: ['jasmine'], + plugins: [ + require('karma-jasmine'), + require('karma-chrome-launcher'), + require('karma-jasmine-html-reporter'), + require('karma-coverage-istanbul-reporter'), + require('karma-webpack'), + ], + // This will be the new entry to webpack + // so it should just be a single file + files: ['src/test.js'], + + // Preprocess test index and test files using + // webpack (will run babel) + preprocessors: { + 'src/test.js': ['webpack'], + 'src/**/*.spec.js': ['webpack'], + }, + + // Reference webpack config (single object) + // and configure some middleware settings + webpack: { + ...webpack({}), + mode: 'development', + }, + webpackMiddleware: { + noInfo: true, + stats: 'errors-only', + }, + + // Typical Karma settings, see docs + reporters: ['progress'], + port: 9876, + colors: true, + logLevel: config.LOG_INFO, + autoWatch: true, + browsers: ['ChromeHeadless'], + singleRun: true, + concurrency: Infinity, + }); +}; +``` + +Now add a unit test for the comment component: + +```javascript +import articleModule from './index'; + +beforeEach(() => { + // Create the module where our functionality can attach to + angular.mock.module('ui.router'); + angular.mock.module(articleModule.name); +}); + +let component; + +beforeEach( + angular.mock.inject(($rootScope, $componentController) => { + let User = { + current: false, + }; + component = $componentController('comment', { User }); + }) +); + +describe('comment component', () => { + it('should be defined', () => { + expect(component).toBeDefined(); + }); + + it('should default canModify to false', () => { + expect(component.canModify).toEqual(false); + }); +}); +``` + +This unit test does a check to make sure the component compiles and that it sets default permissions correctly. + +To run the unit tests: + +```bash +ng test +``` + +You should see green text as your test passes. + +![Unit tests passing](./migration-angularjs-unit-tests-passing.png) + +## End to End testing + +End to End (or E2E) testing is another important part of migration. The more tests you have to verify your code, the easier it is to confirm that your code works the same way it did before. Again, the realworld application doesn’t have any e2e tests, so you need to add your own. + +Nx created `realworld-e2e` for you when you generated your app. There is an example test already generated in `apps/realworld-e2e/src/app.e2e-spec.ts`. It has a helper file named `app.po.ts`. The `spec` file contains the actual tests, while the `po` file contains helper functions to retrieve information about the page. The generated test checks to make sure the title of the app is displayed properly, an indication that the app bootstrapped properly in the browser. + +You need to modify these files to account for the RealWorld app layout. Make the following modifications: + +```typescript +//app.e2e-spec.ts +import { AppPage } from './app.po'; +import { browser, logging } from 'protractor'; + +describe('workspace-project App', () => { + let page: AppPage; + + beforeEach(() => { + page = new AppPage(); + }); + + it('should display app title', () => { + page.navigateTo(); + expect(page.getTitleText()).toEqual('conduit'); + }); + + afterEach(async () => { + // Assert that there are no errors emitted from the browser + const logs = await browser.manage().logs().get(logging.Type.BROWSER); + expect(logs).not.toContain( + jasmine.objectContaining({ + level: logging.Level.SEVERE, + } as logging.Entry) + ); + }); +}); +``` + +```typescript +// app.po.ts +import { browser, by, element } from 'protractor'; + +export class AppPage { + navigateTo(): Promise { + return browser.get(browser.baseUrl) as Promise; + } + + getTitleText(): Promise { + return element(by.css('h1.logo-font')).getText() as Promise; + } +} +``` + +To run e2e tests, use the `e2e` command: + +```bash +ng e2e +``` + +You should see a browser pop up to run the Protractor tests and then green success text in your console. + +## Summary + +- Nx workspaces can be customized to support AngularJS projects +- AngularJS projects can be migrated into an Nx workspace using existing build and serve processes +- Switching to Webpack can enable your Angular upgrade success later +- Unit testing and e2e testing can be used on AngularJS projects and can help ensure a successful migration diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/01-create-application.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/01-create-application.md new file mode 100644 index 0000000000..24a9ebf073 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/01-create-application.md @@ -0,0 +1,130 @@ +# Angular Nx Tutorial - Step 1: Create Application + +## Nx.dev Tutorial | Angular | Step 1: Create Application + + + +In this tutorial you will use Nx to build a full-stack application out of common libraries using modern technologies like Cypress and Nest. + +## Create a New Workspace + +**Start by creating a new workspace.** + +```bash +npx create-nx-workspace@latest +``` + +You will then receive the following prompts in your command line: + +``` +? Workspace name (e.g., org name) myorg +? What to create in the new workspace angular +? Application name todos +? Default stylesheet format CSS +``` + +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.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── tslint.json +│   └── todos-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tsconfig.json +│      └── tslint.json +├── libs/ +├── tools/ +├── angular.json +├── nx.json +├── package.json +├── tsconfig.json +├── tslint.json +└── README.md +``` + +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 `npm run`: + +```bash +npm run nx -- serve todos +``` + +or + +```bash +yarn nx serve todos +``` + +## Note on `nx serve` and `ng serve` + +Internally, the Nx CLI delegates to the Angular CLI when running commands or generating code. 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 `ng` will result in the same output, but often will perform a lot better. [Read more about Nx CLI and Angular CLI.](/angular/getting-started/nx-and-cli) + +!!!!! +Open http://localhost:4200 in the browser. What do you see? +!!!!! +Page saying "Welcome to Todos!" +Page saying "This is an Angular app built with the Angular CLI" +404 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/02-add-e2e-test.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/02-add-e2e-test.md new file mode 100644 index 0000000000..9fb006e7c4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/02-add-e2e-test.md @@ -0,0 +1,48 @@ +# Angular Nx Tutorial - Step 2: Add E2E Tests + +## Nx.dev Tutorial | Angular | Step 2: Add E2E Test + + + +By default, Nx uses [Cypress](/{{framework}}/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 not a great example of an E2E test, but it will suffice 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 will open. Click the button in the top right corner that says "Run all specs". Keep the E2E tests running. + +As you progress through the tutorial, you will work on making these E2E tests pass. + +!!!!! +What assertion fails? +!!!!! +Expect 0 to equal 2 +Nothing fails. Everything works. +Cannot find any elements matching 'li.todo' +Cannot find any elements matching 'button#add-todo' diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/03-display-todos.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/03-display-todos.md new file mode 100644 index 0000000000..01bdf0268d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/03-display-todos.md @@ -0,0 +1,89 @@ +# Angular Nx Tutorial - Step 3: Display Todos + +## Nx.dev Tutorial | Angular | 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 test will 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 will you see if you run: `npx nx e2e todos-e2e --headless` +!!!!! +Cypress will run in the headless mode, and the test will pass. +Cypress will run in the headless mode, and the test will fail. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/04-connect-to-api.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/04-connect-to-api.md new file mode 100644 index 0000000000..5ebaba37ea --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/04-connect-to-api.md @@ -0,0 +1,66 @@ +# Angular Nx Tutorial - Step 4: Connect to an API + +## Nx.dev Tutorial | Angular | Step 4: Connect to 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(); + }); + } +} +``` + +!!!!! +Run `npx nx serve todos` and open http://localhost:4200. What do you see? +!!!!! +"the server responded with a status of 404 (Not Found)" in Console. +Blank screen. +Exception rendered on the screen. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/05-add-node-app.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/05-add-node-app.md new file mode 100644 index 0000000000..3fbf934372 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/05-add-node-app.md @@ -0,0 +1,190 @@ +# Angular Nx Tutorial - Step 5: Add Node Application Implementing API + +## Nx.dev Tutorial | Angular | Step 5: Add Node Application Implementing 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 open platform with plugins for many modern tools and frameworks. **To see some plugins, run `nx list`:** + +```bash +> NX Installed plugins: + + @nrwl/angular (builders,schematics) + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/workspace (builders,schematics) + + +> NX Also available: + + @nrwl/express (builders,schematics) + @nrwl/linter (builders) + @nrwl/nest (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-plugin (builders,schematics) + @nrwl/react (builders,schematics) + @nrwl/storybook (builders,schematics) + @nrwl/web (builders,schematics) + + +> NX Community plugins: + + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + @offeringsolutions/nx-karma-to-jest - Nx plugin for replacing karma with jest in an Nx workspace + @dev-thought/nx-deploy-it - Nx plugin to deploy applications on your favorite cloud provider +``` + +**Now run `npx nx list @nrwl/nest`, and you will see:** + +```bash +> NX NOTE @nrwl/nest is not currently installed + + Use "yarn add --dev @nrwl/nest" to add new capabilities +``` + +**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 will ask you a few questions, and, as with the Angular application, the defaults will 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 +│      └── tslint.json +├── libs/ +├── angular.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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](/{{framework}}/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(); + } +} +``` + +!!!!! +Run "npx nx serve api" and open http://localhost:3333/api/todos. What do you see? +!!!!! +`[{"title":"Todo 1"},{"title":"Todo 2"}]` +Blank screen +404 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/06-proxy.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/06-proxy.md new file mode 100644 index 0000000000..67fb24e447 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/06-proxy.md @@ -0,0 +1,50 @@ +# Angular Nx Tutorial - Step 6: Proxy + +## Nx.dev Tutorial | Angular | Step 6: Configure 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 `angular.json` and find the `serve` target of the todos app.** + +```json +{ + "serve": { + "builder": "@angular-devkit/build-angular:dev-server", + "options": { + "browserTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "browserTarget": "todos:build:production" + } + } + } +} +``` + +**Note the `proxyConfig` property.** + +**Now open `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. + +!!!!! +Now run both "npx nx serve todos" and "npx nx serve api" in separate terminals, open http://localhost:4200. What do you see +!!!!! +Todos application is working! +404 in the console +Todos are displayed but the Add Todo button doesn't work diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/07-share-code.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/07-share-code.md new file mode 100644 index 0000000000..10f551ce4d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/07-share-code.md @@ -0,0 +1,118 @@ +# Angular Nx Tutorial - Step 7: Share Code + +## Nx.dev Tutorial | Angular | 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 generator 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.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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 recognised. This may need to be done **every time a new workspace library is added**. + +## 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`. **So restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between frontend and backend apps +Between different frontend apps +Between different node apps diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/08-create-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/08-create-libs.md new file mode 100644 index 0000000000..dfaa83cd14 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/08-create-libs.md @@ -0,0 +1,163 @@ +# Angular Nx Tutorial - Step 8: Create Libs + +## Nx.dev Tutorial | Angular | Step 8: Create Libraries + + + +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. + +**Run `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.spec.ts +│      │   │ └── ui.module.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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.spec.ts +│      │   │ └── ui.module.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      ├── tsconfig.spec.json +│      └── tslint.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.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 both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +angular.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/09-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/09-dep-graph.md new file mode 100644 index 0000000000..9eefe9d759 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/09-dep-graph.md @@ -0,0 +1,18 @@ +# Angular Nx Tutorial - Step 9: Dep Graph + +## Nx.dev Tutorial | Angular | Step 9: Dep Graph + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "npm run dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/10-computation-caching.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/10-computation-caching.md new file mode 100644 index 0000000000..73bed9d0f0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/10-computation-caching.md @@ -0,0 +1,108 @@ +# Angular Nx Tutorial - Step 10: Computation Caching + +## Nx.dev Tutorial | Angular | Step 10: Use 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 +> npx nx run todos:build +Generating ES5 bundles for differential loading... +ES5 bundle generation complete. + +chunk {runtime} runtime-es2015.js, runtime-es2015.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {runtime} runtime-es5.js, runtime-es5.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {polyfills} polyfills-es2015.js, polyfills-es2015.js.map (polyfills) 141 kB [initial] [rendered] +chunk {main} main-es2015.js, main-es2015.js.map (main) 22.7 kB [initial] [rendered] +chunk {main} main-es5.js, main-es5.js.map (main) 24.1 kB [initial] [rendered] +chunk {styles} styles-es2015.js, styles-es2015.js.map (styles) 9.88 kB [initial] [rendered] +chunk {styles} styles-es5.js, styles-es5.js.map (styles) 11.1 kB [initial] [rendered] +chunk {polyfills-es5} polyfills-es5.js, polyfills-es5.js.map (polyfills-es5) 759 kB [initial] [rendered] +chunk {vendor} vendor-es2015.js, vendor-es2015.js.map (vendor) 2.35 MB [initial] [rendered] +chunk {vendor} vendor-es5.js, vendor-es5.js.map (vendor) 2.75 MB [initial] [rendered] +``` + +**Now, run `npx nx build todos` again, and you will see the results appearing instantly:** + +```bash +> npx nx run todos:build + +> NX NOTE Cached Output: + +Generating ES5 bundles for differential loading... +ES5 bundle generation complete. + +chunk {polyfills-es5} polyfills-es5.js, polyfills-es5.js.map (polyfills-es5) 759 kB [initial] [rendered] +chunk {polyfills} polyfills-es2015.js, polyfills-es2015.js.map (polyfills) 141 kB [initial] [rendered] +chunk {main} main-es2015.js, main-es2015.js.map (main) 22.5 kB [initial] [rendered] +chunk {main} main-es5.js, main-es5.js.map (main) 23.9 kB [initial] [rendered] +chunk {vendor} vendor-es2015.js, vendor-es2015.js.map (vendor) 2.35 MB [initial] [rendered] +chunk {vendor} vendor-es5.js, vendor-es5.js.map (vendor) 2.75 MB [initial] [rendered] +chunk {styles} styles-es2015.js, styles-es2015.js.map (styles) 9.88 kB [initial] [rendered] +chunk {styles} styles-es5.js, styles-es5.js.map (styles) 11.1 kB [initial] [rendered] +chunk {runtime} runtime-es2015.js, runtime-es2015.js.map (runtime) 6.16 kB [entry] [rendered] +chunk {runtime} runtime-es5.js, runtime-es5.js.map (runtime) 6.16 kB [entry] [rendered] +``` + +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` will run the command every single time. + +## Building Multiple Projects + +**Now, run `npx nx run-many --target=build --projects=todos,api` to rebuild the two applications:** + +```bash +Nx read the output from cache instead of running the command for 1 out of 2 projects. +``` + +Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache here [here](/{{framework}}/core-concepts/computation-caching). + +## --with-deps + +As we saw already, Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `npx nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> npx nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +> npx nx run ui:lint + +Linting "ui"... + +All files pass linting. + + +> npx nx run data:lint + +Linting "data"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `npx nx lint api --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 2 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/11-test-affected-projects.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/11-test-affected-projects.md new file mode 100644 index 0000000000..b5c984b962 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/11-test-affected-projects.md @@ -0,0 +1,70 @@ +# Angular Nx Tutorial - Step 11: Test Affected Projects + +## Nx.dev Tutorial | Angular | Step 11: Test Affected Projects + + + +Because Nx understands the dependency graph of your workspace, Nx can be 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 `npm run affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps can be affected by this change. + +**Run `npm run affected:libs`**, and 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 `npx nx affected:test` to retest only the projects affected by the change.** + +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 `npm run affected:test -- --only-failed` to retest the failed projects.** + +## 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 +``` + +!!!!! +Run "npx nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects to run test +The `todos` project failed as before +`Cannot run tests against master` error diff --git a/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/12-summary.md b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/12-summary.md new file mode 100644 index 0000000000..129254b8cb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/angular/tutorial/12-summary.md @@ -0,0 +1,18 @@ +# 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 dep graph capabilities 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](/{{framework}}/getting-started/cli-overview) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/builders.json b/nx-dev/data-access-documents/src/data/11.4.0/builders.json new file mode 100644 index 0000000000..d147d35dea --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/builders.json @@ -0,0 +1,11 @@ +[ + "cypress", + "express", + "jest", + "linter", + "nest", + "node", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/map.json b/nx-dev/data-access-documents/src/data/11.4.0/map.json new file mode 100644 index 0000000000..a961fd05d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/map.json @@ -0,0 +1,3025 @@ +[ + { + "id": "angular", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "file": "angular/getting-started/getting-started" + }, + { + "name": "Resources", + "id": "resources" + }, + { + "name": "Nx and Angular CLI", + "id": "nx-and-cli", + "file": "angular/getting-started/nx-and-cli" + }, + { + "name": "CLI Overview", + "searchResultsName": "CLI Overview", + "id": "cli-overview", + "file": "angular/guides/cli-overview" + }, + { + "name": "VS Code Plugin", + "id": "console", + "file": "shared/console" + }, + { + "name": "Folder Structure", + "searchResultsName": "Folder Structure", + "id": "folder-structure", + "file": "shared/folder-structure" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "angular/guides/configuration" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Add E2E Test", + "id": "02-add-e2e-test" + }, + { + "name": "3 - Display Todos", + "id": "03-display-todos" + }, + { + "name": "4 - Connect to API", + "id": "04-connect-to-api" + }, + { + "name": "5 - Add Node Application", + "id": "05-add-node-app" + }, + { + "name": "6 - Configure Proxy", + "id": "06-proxy" + }, + { + "name": "7 - Share Code", + "id": "07-share-code" + }, + { + "name": "8 - Create Libraries", + "id": "08-create-libs" + }, + { + "name": "9 - Dep Graph", + "id": "09-dep-graph" + }, + { + "name": "10 - Use Computation Caching", + "id": "10-computation-caching" + }, + { + "name": "11 - Test Affected Projects", + "id": "11-test-affected-projects" + }, + { + "name": "12 - Summary", + "id": "12-summary" + } + ] + }, + { + "name": "Core Concepts", + "id": "core-concepts", + "itemList": [ + { + "name": "Plugins", + "id": "plugins", + "file": "shared/plugins-overview" + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Rebuild Only What is Affected", + "id": "affected", + "file": "shared/affected" + }, + { + "name": "Why Monorepos", + "id": "why-monorepos", + "file": "shared/guides/why-monorepos" + }, + { + "name": "Updating Nx", + "id": "updating-nx", + "file": "angular/guides/update" + }, + { + "name": "Nx Devkit", + "id": "nx-devkit", + "file": "shared/devkit" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + }, + { + "name": "From Angular CLI", + "id": "migration-angular" + }, + { + "name": "From AngularJS", + "id": "migration-angularjs" + }, + { + "name": "Adding to Monorepo", + "id": "adding-to-monorepo", + "file": "shared/migration/adding-to-monorepo" + }, + { + "name": "Preserving Git Histories", + "id": "preserving-git-histories", + "file": "shared/migration/preserving-git-histories" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "generate", + "id": "generate", + "file": "angular/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "angular/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "angular/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "angular/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "angular/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "angular/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "angular/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "angular/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "angular/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "angular/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "angular/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "angular/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "angular/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "angular/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "angular/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "angular/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "angular/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "angular/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "angular/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "angular/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "angular/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "angular/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "angular/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "angular/cli/workspace-lint" + }, + { + "name": "workspace-generator", + "id": "workspace-generator", + "file": "angular/cli/workspace-generator" + } + ] + }, + { + "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": "angular/api-workspace/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "angular/api-workspace/generators/move" + }, + { + "name": "remove generator", + "id": "remove", + "file": "angular/api-workspace/generators/remove" + }, + { + "name": "run-commands generator", + "id": "run-commands-generator", + "file": "angular/api-workspace/generators/run-commands" + }, + { + "name": "workspace-generator generator", + "id": "workspace-generator", + "file": "angular/api-workspace/generators/workspace-generator" + }, + { + "name": "run-commands executor", + "id": "run-commands-executor", + "file": "angular/api-workspace/executors/run-commands" + }, + { + "name": "run-script executor", + "id": "run-script", + "file": "angular/api-workspace/executors/run-script" + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-web/generators/application" + }, + { + "name": "build executor", + "id": "build", + "file": "angular/api-web/executors/build" + }, + { + "name": "dev-server executor", + "id": "dev-server", + "file": "angular/api-web/executors/dev-server" + }, + { + "name": "file-server executor", + "id": "file-server", + "file": "angular/api-web/executors/file-server" + }, + { + "name": "package executor", + "id": "package", + "file": "angular/api-web/executors/package" + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-angular/generators/application" + }, + { + "name": "downgrade-module generator", + "id": "downgrade-module", + "file": "angular/api-angular/generators/downgrade-module" + }, + { + "name": "karma-project generator", + "id": "karma-project", + "file": "angular/api-angular/generators/karma-project" + }, + { + "name": "karma generator", + "id": "karma", + "file": "angular/api-angular/generators/karma" + }, + { + "name": "library generator", + "id": "library", + "file": "angular/api-angular/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "angular/api-angular/generators/move" + }, + { + "name": "ngrx generator", + "id": "ngrx", + "file": "angular/api-angular/generators/ngrx" + }, + { + "name": "stories generator", + "id": "stories", + "file": "angular/api-angular/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "angular/api-angular/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "angular/api-angular/generators/storybook-migrate-defaults-5-to-6" + }, + { + "name": "upgrade-module generator", + "id": "upgrade-module", + "file": "angular/api-angular/generators/upgrade-module" + }, + { + "name": "package executor", + "id": "package", + "file": "angular/api-angular/executors/package" + }, + { + "name": "ng packagr lite executor", + "id": "ng-packagr-lite", + "file": "angular/api-angular/executors/ng-packagr-lite" + }, + { + "name": "webpack-browser executor", + "id": "webpack-browser", + "file": "angular/api-angular/executors/webpack-browser" + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-react/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "angular/api-react/generators/component" + }, + { + "name": "component-cypress-spec generator", + "id": "component-cypress-spec", + "file": "angular/api-react/generators/component-cypress-spec" + }, + { + "name": "component-story generator", + "id": "component-story", + "file": "angular/api-react/generators/component-story" + }, + { + "name": "library generator", + "id": "library", + "file": "angular/api-react/generators/library" + }, + { + "name": "redux generator", + "id": "redux", + "file": "angular/api-react/generators/redux" + }, + { + "name": "stories generator", + "id": "stories", + "file": "angular/api-react/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "angular/api-react/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "angular/api-react/generators/storybook-migrate-defaults-5-to-6" + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "name": "jest executor", + "id": "jest", + "file": "angular/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": "angular/api-cypress/executors/cypress" + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/storybook Overview", + "file": "angular/guides/storybook-plugin" + }, + { + "name": "configuration generator", + "id": "configuration", + "file": "angular/api-storybook/generators/configuration" + }, + { + "name": "migrate-defaults-5-to-6 generator", + "id": "migrate-defaults-5-to-6", + "file": "angular/api-storybook/generators/migrate-defaults-5-to-6" + }, + { + "name": "cypress-project generator", + "id": "cypress-project", + "file": "angular/api-storybook/generators/cypress-project" + }, + { + "name": "build executor", + "id": "build", + "file": "angular/api-storybook/executors/build" + }, + { + "name": "storybook executor", + "id": "storybook", + "file": "angular/api-storybook/executors/storybook" + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "name": "eslint executor", + "id": "eslint", + "file": "angular/api-linter/executors/eslint" + }, + { + "name": "lint executor", + "id": "lint", + "file": "angular/api-linter/executors/lint" + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-node/generators/application" + }, + { + "name": "library generator", + "id": "library", + "file": "angular/api-node/generators/library" + }, + { + "name": "build executor", + "id": "build", + "file": "angular/api-node/executors/build" + }, + { + "name": "execute executor", + "id": "execute", + "file": "angular/api-node/executors/execute" + }, + { + "name": "package executor", + "id": "package", + "file": "angular/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": "angular/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": "angular/api-nest/generators/application" + }, + { + "name": "class generator", + "id": "class", + "file": "angular/api-nest/generators/class" + }, + { + "name": "controller generator", + "id": "controller", + "file": "angular/api-nest/generators/controller" + }, + { + "name": "decorator generator", + "id": "decorator", + "file": "angular/api-nest/generators/decorator" + }, + { + "name": "filter generator", + "id": "filter", + "file": "angular/api-nest/generators/filter" + }, + { + "name": "gateway generator", + "id": "gateway", + "file": "angular/api-nest/generators/gateway" + }, + { + "name": "guard generator", + "id": "guard", + "file": "angular/api-nest/generators/guard" + }, + { + "name": "interceptor generator", + "id": "interceptor", + "file": "angular/api-nest/generators/interceptor" + }, + { + "name": "interface generator", + "id": "interface", + "file": "angular/api-nest/generators/interface" + }, + { + "name": "library generator", + "id": "library", + "file": "angular/api-nest/generators/library" + }, + { + "name": "middleware generator", + "id": "middleware", + "file": "angular/api-nest/generators/middleware" + }, + { + "name": "module generator", + "id": "module", + "file": "angular/api-nest/generators/module" + }, + { + "name": "pipe generator", + "id": "pipe", + "file": "angular/api-nest/generators/pipe" + }, + { + "name": "provider generator", + "id": "provider", + "file": "angular/api-nest/generators/provider" + }, + { + "name": "resolver generator", + "id": "resolver", + "file": "angular/api-nest/generators/resolver" + }, + { + "name": "service generator", + "id": "service", + "file": "angular/api-nest/generators/service" + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-next/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "angular/api-next/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "angular/api-next/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "angular/api-next/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "angular/api-next/executors/server" + }, + { + "name": "export executor", + "id": "export", + "file": "angular/api-next/executors/export" + } + ] + }, + { + "name": "gatsby", + "id": "gatsby", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/gatsby Overview", + "file": "shared/gatsby-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "angular/api-gatsby/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "angular/api-gatsby/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "angular/api-gatsby/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "angular/api-gatsby/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "angular/api-gatsby/executors/server" + } + ] + }, + { + "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": "angular/api-nx-plugin/generators/executor" + }, + { + "name": "migration generator", + "id": "migration", + "file": "angular/api-nx-plugin/generators/migration" + }, + { + "name": "plugin generator", + "id": "plugin", + "file": "angular/api-nx-plugin/generators/plugin" + }, + { + "name": "generator generator", + "id": "schematic", + "file": "angular/api-nx-plugin/generators/generator" + }, + { + "name": "e2e executor", + "id": "e2e", + "file": "angular/api-nx-plugin/executors/e2e" + } + ] + }, + { + "name": "Executors / Builders", + "id": "executors", + "itemList": [ + { + "name": "Using Executors / Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "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/using-schematics" + }, + { + "name": "Workspace Generators", + "id": "workspace-generators", + "file": "shared/tools-workspace-generators" + } + ] + }, + { + "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + }, + { + "name": "Setup incremental builds for Angular applications", + "id": "setup-incremental-builds-angular", + "file": "angular/guides/setup-incremental-builds" + } + ] + }, + { + "name": "Modern Angular", + "id": "modern-angular", + "itemList": [ + { + "name": "Moving from Protractor to Cypress", + "id": "protractor-to-cypress", + "file": "angular/guides/modern-angular/protractor-to-cypress" + }, + { + "name": "Moving from Karma to Jest", + "id": "karma-to-jest", + "file": "angular/guides/modern-angular/karma-to-jest" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "Using NgRx", + "id": "misc-ngrx" + }, + { + "name": "Using DataPersistence", + "id": "misc-data-persistence" + }, + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + }, + { + "name": "Nx 7 => Nx 8", + "id": "nx7-to-nx8" + }, + { + "name": "Upgrading AngularJS Applications", + "id": "misc-upgrade" + }, + { + "name": "Configuring Browser Support", + "id": "browser-support", + "file": "shared/guides/browser-support" + }, + { + "name": "Running custom commands", + "id": "running-custom-commands", + "file": "angular/guides/running-custom-commands" + }, + { + "name": "Nx Devkit and Angular Devkit", + "id": "nx-devkit-angular-devkit", + "file": "angular/guides/nx-devkit-angular-devkit" + } + ] + }, + { + "name": "Examples", + "id": "examples", + "itemList": [ + { + "name": "Nx Micro-Frontend Example", + "id": "nx-examples", + "file": "shared/examples/nx-examples" + }, + { + "name": "Building Angular and React Applications Together With Nx", + "id": "react-and-angular", + "file": "angular/examples/react-and-angular" + }, + { + "name": "Using Apollo GraphQL", + "id": "apollo-angular", + "file": "angular/examples/apollo-angular" + } + ] + } + ] + }, + { + "id": "react", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "file": "react/getting-started/getting-started" + }, + { + "name": "Resources", + "id": "resources" + }, + { + "name": "CLI Overview", + "searchResultsName": "CLI Overview", + "id": "cli-overview", + "file": "react/guides/cli-overview" + }, + { + "name": "VS Code Plugin", + "id": "console", + "file": "shared/console" + }, + { + "name": "Folder Structure", + "searchResultsName": "Folder Structure", + "id": "folder-structure", + "file": "shared/folder-structure" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "react/guides/configuration" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Add E2E Test", + "id": "02-add-e2e-test" + }, + { + "name": "3 - Display Todos", + "id": "03-display-todos" + }, + { + "name": "4 - Connect to API", + "id": "04-connect-to-api" + }, + { + "name": "5 - Add Node Application", + "id": "05-add-node-app" + }, + { + "name": "6 - Configure Proxy", + "id": "06-proxy" + }, + { + "name": "7 - Share Code", + "id": "07-share-code" + }, + { + "name": "8 - Create Libraries", + "id": "08-create-libs" + }, + { + "name": "9 - Dep Graph", + "id": "09-dep-graph" + }, + { + "name": "10 - Use Computation Caching", + "id": "10-computation-caching" + }, + { + "name": "11 - Test Affected Projects", + "id": "11-test-affected-projects" + }, + { + "name": "12 - Summary", + "id": "12-summary" + } + ] + }, + { + "name": "Core Concepts", + "id": "core-concepts", + "itemList": [ + { + "name": "Plugins", + "id": "plugins", + "file": "shared/plugins-overview" + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Rebuild Only What is Affected", + "id": "affected", + "file": "shared/affected" + }, + { + "name": "Why Monorepos", + "id": "why-monorepos", + "file": "shared/guides/why-monorepos" + }, + { + "name": "Updating Nx", + "id": "updating-nx", + "file": "shared/update" + }, + { + "name": "Nx Devkit", + "id": "nx-devkit", + "file": "shared/devkit" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + }, + { + "name": "From CRA", + "id": "migration-cra" + }, + { + "name": "Adding to Monorepo", + "id": "adding-to-monorepo", + "file": "shared/migration/adding-to-monorepo" + }, + { + "name": "Preserving Git Histories", + "id": "preserving-git-histories", + "file": "shared/migration/preserving-git-histories" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "generate", + "id": "generate", + "file": "react/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "react/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "react/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "react/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "react/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "react/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "react/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "react/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "react/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "react/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "react/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "react/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "react/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "react/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "react/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "react/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "react/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "react/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "react/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "react/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "react/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "react/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "react/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "react/cli/workspace-lint" + }, + { + "name": "workspace-generator", + "id": "workspace-generator", + "file": "react/cli/workspace-generator" + } + ] + }, + { + "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": "react/api-workspace/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "react/api-workspace/generators/move" + }, + { + "name": "remove generator", + "id": "remove", + "file": "react/api-workspace/generators/remove" + }, + { + "name": "run-commands generator", + "id": "run-commands-generator", + "file": "react/api-workspace/generators/run-commands" + }, + { + "name": "workspace-generator generator", + "id": "workspace-generator", + "file": "react/api-workspace/generators/workspace-generator" + }, + { + "name": "run-commands executor", + "id": "run-commands-executor", + "file": "react/api-workspace/executors/run-commands" + }, + { + "name": "run-script executor", + "id": "run-script", + "file": "react/api-workspace/executors/run-script" + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-web/generators/application" + }, + { + "name": "build executor", + "id": "build", + "file": "react/api-web/executors/build" + }, + { + "name": "dev-server executor", + "id": "dev-server", + "file": "react/api-web/executors/dev-server" + }, + { + "name": "file-server executor", + "id": "file-server", + "file": "react/api-web/executors/file-server" + }, + { + "name": "package executor", + "id": "package", + "file": "react/api-web/executors/package" + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-angular/generators/application" + }, + { + "name": "downgrade-module generator", + "id": "downgrade-module", + "file": "react/api-angular/generators/downgrade-module" + }, + { + "name": "karma-project generator", + "id": "karma-project", + "file": "react/api-angular/generators/karma-project" + }, + { + "name": "karma generator", + "id": "karma", + "file": "react/api-angular/generators/karma" + }, + { + "name": "library generator", + "id": "library", + "file": "react/api-angular/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "react/api-angular/generators/move" + }, + { + "name": "ngrx generator", + "id": "ngrx", + "file": "react/api-angular/generators/ngrx" + }, + { + "name": "stories generator", + "id": "stories", + "file": "react/api-angular/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "react/api-angular/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "react/api-angular/generators/storybook-migrate-defaults-5-to-6" + }, + { + "name": "upgrade-module generator", + "id": "upgrade-module", + "file": "react/api-angular/generators/upgrade-module" + }, + { + "name": "package executor", + "id": "package", + "file": "react/api-angular/executors/package" + }, + { + "name": "ng packagr lite executor", + "id": "ng-packagr-lite", + "file": "react/api-angular/executors/ng-packagr-lite" + }, + { + "name": "webpack-browser executor", + "id": "webpack-browser", + "file": "react/api-angular/executors/webpack-browser" + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-react/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "react/api-react/generators/component" + }, + { + "name": "component-cypress-spec generator", + "id": "component-cypress-spec", + "file": "react/api-react/generators/component-cypress-spec" + }, + { + "name": "component-story generator", + "id": "component-story", + "file": "react/api-react/generators/component-story" + }, + { + "name": "library generator", + "id": "library", + "file": "react/api-react/generators/library" + }, + { + "name": "redux generator", + "id": "redux", + "file": "react/api-react/generators/redux" + }, + { + "name": "stories generator", + "id": "stories", + "file": "react/api-react/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "react/api-react/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "react/api-react/generators/storybook-migrate-defaults-5-to-6" + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "name": "jest executor", + "id": "jest", + "file": "react/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": "react/api-cypress/executors/cypress" + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/storybook Overview", + "file": "react/guides/storybook-plugin" + }, + { + "name": "configuration generator", + "id": "configuration", + "file": "react/api-storybook/generators/configuration" + }, + { + "name": "cypress-project generator", + "id": "cypress-project", + "file": "react/api-storybook/generators/cypress-project" + }, + { + "name": "migrate-defaults-5-to-6 generator", + "id": "migrate-defaults-5-to-6", + "file": "react/api-storybook/generators/migrate-defaults-5-to-6" + }, + { + "id": "executors", + "name": "Executors / Builders", + "itemList": [ + { + "name": "build", + "id": "build", + "file": "react/api-storybook/executors/build" + }, + { + "name": "storybook", + "id": "storybook", + "file": "react/api-storybook/executors/storybook" + } + ] + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "name": "eslint executor", + "id": "eslint", + "file": "react/api-linter/executors/eslint" + }, + { + "name": "lint executor", + "id": "lint", + "file": "react/api-linter/executors/lint" + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-node/generators/application" + }, + { + "name": "library generator", + "id": "library", + "file": "react/api-node/generators/library" + }, + { + "name": "build executor", + "id": "build", + "file": "react/api-node/executors/build" + }, + { + "name": "execute executor", + "id": "execute", + "file": "react/api-node/executors/execute" + }, + { + "name": "package executor", + "id": "package", + "file": "react/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": "react/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": "react/api-nest/generators/application" + }, + { + "name": "class generator", + "id": "class", + "file": "react/api-nest/generators/class" + }, + { + "name": "controller generator", + "id": "controller", + "file": "react/api-nest/generators/controller" + }, + { + "name": "decorator generator", + "id": "decorator", + "file": "react/api-nest/generators/decorator" + }, + { + "name": "filter generator", + "id": "filter", + "file": "react/api-nest/generators/filter" + }, + { + "name": "gateway generator", + "id": "gateway", + "file": "react/api-nest/generators/gateway" + }, + { + "name": "guard generator", + "id": "guard", + "file": "react/api-nest/generators/guard" + }, + { + "name": "interceptor generator", + "id": "interceptor", + "file": "react/api-nest/generators/interceptor" + }, + { + "name": "interface generator", + "id": "interface", + "file": "react/api-nest/generators/interface" + }, + { + "name": "library generator", + "id": "library", + "file": "react/api-nest/generators/library" + }, + { + "name": "middleware generator", + "id": "middleware", + "file": "react/api-nest/generators/middleware" + }, + { + "name": "module generator", + "id": "module", + "file": "react/api-nest/generators/module" + }, + { + "name": "pipe generator", + "id": "pipe", + "file": "react/api-nest/generators/pipe" + }, + { + "name": "provider generator", + "id": "provider", + "file": "react/api-nest/generators/provider" + }, + { + "name": "resolver generator", + "id": "resolver", + "file": "react/api-nest/generators/resolver" + }, + { + "name": "service generator", + "id": "service", + "file": "react/api-nest/generators/service" + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-next/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "react/api-next/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "react/api-next/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "react/api-next/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "react/api-next/executors/server" + }, + { + "name": "export executor", + "id": "export", + "file": "react/api-next/executors/export" + } + ] + }, + { + "name": "gatsby", + "id": "gatsby", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/gatsby Overview", + "file": "shared/gatsby-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "react/api-gatsby/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "react/api-gatsby/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "react/api-gatsby/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "react/api-gatsby/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "react/api-gatsby/executors/server" + } + ] + }, + { + "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": "react/api-nx-plugin/generators/executor" + }, + { + "name": "migration generator", + "id": "migration", + "file": "react/api-nx-plugin/generators/migration" + }, + { + "name": "plugin generator", + "id": "plugin", + "file": "react/api-nx-plugin/generators/plugin" + }, + { + "name": "generator generator", + "id": "schematic", + "file": "react/api-nx-plugin/generators/generator" + }, + { + "name": "e2e executor", + "id": "e2e", + "file": "react/api-nx-plugin/executors/e2e" + } + ] + }, + { + "name": "Executors / Builders", + "id": "executors", + "itemList": [ + { + "name": "Using Executors / Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "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/using-schematics" + }, + { + "name": "Workspace Generators", + "id": "workspace-generators", + "file": "shared/tools-workspace-generators" + } + ] + }, + { + "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "Adding Images, Fonts, and Files", + "id": "adding-assets-react", + "file": "react/guides/adding-assets" + }, + { + "name": "Using Environment Variables", + "id": "environment-variables", + "file": "react/guides/environment-variables" + }, + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + }, + { + "name": "JavaScript and TypeScript", + "id": "js-and-ts", + "file": "react/guides/js-and-ts" + }, + { + "name": "Configuring Browser Support", + "id": "browser-support", + "file": "shared/guides/browser-support" + }, + { + "name": "Next.js projects with Nx", + "id": "nextjs", + "file": "react/guides/nextjs" + } + ] + }, + { + "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": "react/examples/react-nx" + }, + { + "name": "Using Apollo GraphQL", + "id": "apollo-react", + "file": "react/examples/apollo-react" + } + ] + } + ] + }, + { + "id": "node", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "itemList": [ + { + "name": "Getting Started", + "id": "getting-started", + "file": "node/getting-started/getting-started" + }, + { + "name": "Resources", + "id": "resources" + }, + { + "name": "CLI Overview", + "searchResultsName": "CLI Overview", + "id": "cli-overview", + "file": "node/guides/cli-overview" + }, + { + "name": "VS Code Plugin", + "id": "console", + "file": "shared/console" + }, + { + "name": "Folder Structure", + "searchResultsName": "Folder Structure", + "id": "folder-structure", + "file": "shared/folder-structure" + }, + { + "name": "Configuration", + "id": "configuration", + "file": "node/guides/configuration" + } + ] + }, + { + "name": "Tutorial", + "id": "tutorial", + "itemList": [ + { + "name": "1 - Create Application", + "id": "01-create-application" + }, + { + "name": "2 - Display Todos", + "id": "02-display-todos" + }, + { + "name": "3 - Share Code", + "id": "03-share-code" + }, + { + "name": "4 - Create Libraries", + "id": "04-create-libs" + }, + { + "name": "5 - Dep Graph", + "id": "05-dep-graph" + }, + { + "name": "6 - Use Computation Caching", + "id": "06-computation-caching" + }, + { + "name": "7 - Test Affected Projects", + "id": "07-test-affected-projects" + }, + { + "name": "8 - Summary", + "id": "08-summary" + } + ] + }, + { + "name": "Core Concepts", + "id": "core-concepts", + "itemList": [ + { + "name": "Plugins", + "id": "plugins", + "file": "shared/plugins-overview" + }, + { + "name": "Computation Caching", + "id": "computation-caching", + "file": "shared/computation-caching" + }, + { + "name": "Rebuild Only What is Affected", + "id": "affected", + "file": "shared/affected" + }, + { + "name": "Why Monorepos", + "id": "why-monorepos", + "file": "shared/guides/why-monorepos" + }, + { + "name": "Updating Nx", + "id": "updating-nx", + "file": "shared/update" + }, + { + "name": "Nx Devkit", + "id": "nx-devkit", + "file": "shared/devkit" + } + ] + }, + { + "name": "Migration", + "id": "migration", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "shared/migration/overview" + }, + { + "name": "Adding to Monorepo", + "id": "adding-to-monorepo", + "file": "shared/migration/adding-to-monorepo" + }, + { + "name": "Preserving Git Histories", + "id": "preserving-git-histories", + "file": "shared/migration/preserving-git-histories" + } + ] + }, + { + "name": "CLI", + "id": "cli", + "itemList": [ + { + "name": "generate", + "id": "generate", + "file": "node/cli/generate" + }, + { + "name": "serve", + "id": "serve", + "file": "node/cli/serve" + }, + { + "name": "build", + "id": "build", + "file": "node/cli/build" + }, + { + "name": "test", + "id": "test", + "file": "node/cli/test" + }, + { + "name": "lint", + "id": "lint", + "file": "node/cli/lint" + }, + { + "name": "e2e", + "id": "e2e", + "file": "node/cli/e2e" + }, + { + "name": "run", + "id": "run", + "file": "node/cli/run" + }, + { + "name": "dep-graph", + "id": "dep-graph", + "file": "node/cli/dep-graph" + }, + { + "name": "run-many", + "id": "run-many", + "file": "node/cli/run-many" + }, + { + "name": "affected", + "id": "affected", + "file": "node/cli/affected" + }, + { + "name": "affected:build", + "id": "affected-build", + "file": "node/cli/affected-build" + }, + { + "name": "affected:test", + "id": "affected-test", + "file": "node/cli/affected-test" + }, + { + "name": "affected:lint", + "id": "affected-lint", + "file": "node/cli/affected-lint" + }, + { + "name": "affected:e2e", + "id": "affected-e2e", + "file": "node/cli/affected-e2e" + }, + { + "name": "affected:dep-graph", + "id": "affected-dep-graph", + "file": "node/cli/affected-dep-graph" + }, + { + "name": "affected:apps", + "id": "affected-apps", + "file": "node/cli/affected-apps" + }, + { + "name": "affected:libs", + "id": "affected-libs", + "file": "node/cli/affected-libs" + }, + { + "name": "print-affected", + "id": "print-affected", + "file": "node/cli/print-affected" + }, + { + "name": "format:check", + "id": "format-check", + "file": "node/cli/format-check" + }, + { + "name": "format:write", + "id": "format-write", + "file": "node/cli/format-write" + }, + { + "name": "migrate", + "id": "migrate", + "file": "node/cli/migrate" + }, + { + "name": "report", + "id": "report", + "file": "node/cli/report" + }, + { + "name": "list", + "id": "list", + "file": "node/cli/list" + }, + { + "name": "workspace-lint", + "id": "workspace-lint", + "file": "node/cli/workspace-lint" + }, + { + "name": "workspace-generator", + "id": "workspace-generator", + "file": "node/cli/workspace-generator" + } + ] + }, + { + "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": "node/api-workspace/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "node/api-workspace/generators/move" + }, + { + "name": "remove generator", + "id": "remove", + "file": "node/api-workspace/generators/remove" + }, + { + "name": "run-commands generator", + "id": "run-commands-generator", + "file": "node/api-workspace/generators/run-commands" + }, + { + "name": "workspace-generator generator", + "id": "workspace-generator", + "file": "node/api-workspace/generators/workspace-generator" + }, + { + "name": "run-commands executor", + "id": "run-commands-executor", + "file": "node/api-workspace/executors/run-commands" + }, + { + "name": "run-script executor", + "id": "run-script", + "file": "node/api-workspace/executors/run-script" + } + ] + }, + { + "name": "web", + "id": "web", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/web Overview", + "file": "shared/web-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-web/generators/application" + }, + { + "name": "build executor", + "id": "build", + "file": "node/api-web/executors/build" + }, + { + "name": "dev-server executor", + "id": "dev-server", + "file": "node/api-web/executors/dev-server" + }, + { + "name": "file-server executor", + "id": "file-server", + "file": "node/api-web/executors/file-server" + }, + { + "name": "package executor", + "id": "package", + "file": "node/api-web/executors/package" + } + ] + }, + { + "name": "angular", + "id": "angular", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/angular Overview", + "file": "shared/angular-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-angular/generators/application" + }, + { + "name": "downgrade-module generator", + "id": "downgrade-module", + "file": "node/api-angular/generators/downgrade-module" + }, + { + "name": "karma-project generator", + "id": "karma-project", + "file": "node/api-angular/generators/karma-project" + }, + { + "name": "karma generator", + "id": "karma", + "file": "node/api-angular/generators/karma" + }, + { + "name": "library generator", + "id": "library", + "file": "node/api-angular/generators/library" + }, + { + "name": "move generator", + "id": "move", + "file": "node/api-angular/generators/move" + }, + { + "name": "ngrx generator", + "id": "ngrx", + "file": "node/api-angular/generators/ngrx" + }, + { + "name": "stories generator", + "id": "stories", + "file": "node/api-angular/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "node/api-angular/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "node/api-angular/generators/storybook-migrate-defaults-5-to-6" + }, + { + "name": "upgrade-module generator", + "id": "upgrade-module", + "file": "node/api-angular/generators/upgrade-module" + }, + { + "name": "package executor", + "id": "package", + "file": "node/api-angular/executors/package" + }, + { + "name": "ng packagr lite executor", + "id": "ng-packagr-lite", + "file": "node/api-angular/executors/ng-packagr-lite" + }, + { + "name": "webpack-browser executor", + "id": "webpack-browser", + "file": "node/api-angular/executors/webpack-browser" + } + ] + }, + { + "name": "react", + "id": "react", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/react Overview", + "file": "shared/react-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-react/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "node/api-react/generators/component" + }, + { + "name": "component-cypress-spec generator", + "id": "component-cypress-spec", + "file": "node/api-react/generators/component-cypress-spec" + }, + { + "name": "component-story generator", + "id": "component-story", + "file": "node/api-react/generators/component-story" + }, + { + "name": "library generator", + "id": "library", + "file": "node/api-react/generators/library" + }, + { + "name": "redux generator", + "id": "redux", + "file": "node/api-react/generators/redux" + }, + { + "name": "stories generator", + "id": "stories", + "file": "node/api-react/generators/stories" + }, + { + "name": "storybook-configuration generator", + "id": "storybook-configuration", + "file": "node/api-react/generators/storybook-configuration" + }, + { + "name": "storybook-migrate-defaults-5-to-6 generator", + "id": "storybook-migrate-defaults-5-to-6", + "file": "node/api-react/generators/storybook-migrate-defaults-5-to-6" + } + ] + }, + { + "name": "jest", + "id": "jest", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/jest Overview", + "file": "shared/jest-plugin" + }, + { + "name": "jest executor", + "id": "jest", + "file": "node/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": "node/api-cypress/executors/cypress" + } + ] + }, + { + "name": "storybook", + "id": "storybook", + "itemList": [ + { + "name": "Overview", + "id": "overview", + "file": "node/guides/storybook-plugin" + }, + { + "name": "configuration generator", + "id": "configuration", + "file": "node/api-storybook/generators/configuration" + }, + { + "name": "migrate-defaults-5-to-6 generator", + "id": "migrate-defaults-5-to-6", + "file": "node/api-storybook/generators/migrate-defaults-5-to-6" + }, + { + "name": "cypress-project generator", + "id": "cypress-project", + "file": "node/api-storybook/generators/cypress-project" + }, + { + "name": "build executor", + "id": "build", + "file": "node/api-storybook/executors/build" + }, + { + "name": "storybook executor", + "id": "storybook", + "file": "node/api-storybook/executors/storybook" + } + ] + }, + { + "name": "linter", + "id": "linter", + "itemList": [ + { + "name": "eslint executor", + "id": "eslint", + "file": "node/api-linter/executors/eslint" + }, + { + "name": "lint executor", + "id": "lint", + "file": "node/api-linter/executors/lint" + } + ] + }, + { + "name": "node", + "id": "node", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/node Overview", + "file": "shared/node-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-node/generators/application" + }, + { + "name": "library generator", + "id": "library", + "file": "node/api-node/generators/library" + }, + { + "name": "build executor", + "id": "build", + "file": "node/api-node/executors/build" + }, + { + "name": "execute executor", + "id": "execute", + "file": "node/api-node/executors/execute" + }, + { + "name": "package executor", + "id": "package", + "file": "node/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": "node/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": "node/api-nest/generators/application" + }, + { + "name": "class generator", + "id": "class", + "file": "node/api-nest/generators/class" + }, + { + "name": "controller generator", + "id": "controller", + "file": "node/api-nest/generators/controller" + }, + { + "name": "decorator generator", + "id": "decorator", + "file": "node/api-nest/generators/decorator" + }, + { + "name": "filter generator", + "id": "filter", + "file": "node/api-nest/generators/filter" + }, + { + "name": "gateway generator", + "id": "gateway", + "file": "node/api-nest/generators/gateway" + }, + { + "name": "guard generator", + "id": "guard", + "file": "node/api-nest/generators/guard" + }, + { + "name": "interceptor generator", + "id": "interceptor", + "file": "node/api-nest/generators/interceptor" + }, + { + "name": "interface generator", + "id": "interface", + "file": "node/api-nest/generators/interface" + }, + { + "name": "library generator", + "id": "library", + "file": "node/api-nest/generators/library" + }, + { + "name": "middleware generator", + "id": "middleware", + "file": "node/api-nest/generators/middleware" + }, + { + "name": "module generator", + "id": "module", + "file": "node/api-nest/generators/module" + }, + { + "name": "pipe generator", + "id": "pipe", + "file": "node/api-nest/generators/pipe" + }, + { + "name": "provider generator", + "id": "provider", + "file": "node/api-nest/generators/provider" + }, + { + "name": "resolver generator", + "id": "resolver", + "file": "node/api-nest/generators/resolver" + }, + { + "name": "service generator", + "id": "service", + "file": "node/api-nest/generators/service" + } + ] + }, + { + "name": "next", + "id": "next", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/next Overview", + "file": "shared/next-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-next/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "node/api-next/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "node/api-next/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "node/api-next/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "node/api-next/executors/server" + }, + { + "name": "export executor", + "id": "export", + "file": "node/api-next/executors/export" + } + ] + }, + { + "name": "gatsby", + "id": "gatsby", + "itemList": [ + { + "id": "overview", + "name": "Overview", + "searchResultsName": "@nrwl/gatsby Overview", + "file": "shared/gatsby-plugin" + }, + { + "name": "application generator", + "id": "application", + "file": "node/api-gatsby/generators/application" + }, + { + "name": "component generator", + "id": "component", + "file": "node/api-gatsby/generators/component" + }, + { + "name": "page generator", + "id": "page", + "file": "node/api-gatsby/generators/page" + }, + { + "name": "build executor", + "id": "build", + "file": "node/api-gatsby/executors/build" + }, + { + "name": "server executor", + "id": "server", + "file": "node/api-gatsby/executors/server" + } + ] + }, + { + "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": "node/api-nx-plugin/generators/executor" + }, + { + "name": "migration generator", + "id": "migration", + "file": "node/api-nx-plugin/generators/migration" + }, + { + "name": "plugin generator", + "id": "plugin", + "file": "node/api-nx-plugin/generators/plugin" + }, + { + "name": "generator generator", + "id": "schematic", + "file": "node/api-nx-plugin/generators/generator" + }, + { + "name": "e2e executor", + "id": "e2e", + "file": "node/api-nx-plugin/executors/e2e" + } + ] + }, + { + "name": "Executors / Builders", + "id": "executors", + "itemList": [ + { + "name": "Using Executors / Builders", + "id": "using-builders", + "file": "shared/using-builders" + }, + { + "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/using-schematics" + }, + { + "name": "Workspace Generators", + "id": "workspace-generators", + "file": "shared/tools-workspace-generators" + } + ] + }, + { + "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": "Dependency Graph", + "id": "dependency-graph", + "file": "shared/workspace/structure/dependency-graph" + } + ] + }, + { + "name": "CI", + "id": "ci", + "itemList": [ + { + "name": "Distributed CI: Overview", + "id": "distributed-builds", + "file": "shared/distributed-builds" + }, + { + "name": "Distributed CI: Azure", + "id": "monorepo-ci-azure", + "file": "shared/monorepo-ci-azure" + }, + { + "name": "Distributed CI: Jenkins", + "id": "monorepo-ci-jenkins", + "file": "shared/monorepo-ci-jenkins" + }, + { + "name": "Incremental Builds", + "id": "incremental-builds", + "file": "shared/incremental-builds" + } + ] + }, + { + "name": "Guides", + "id": "guides", + "itemList": [ + { + "name": "Using Nx at Enterprises", + "id": "monorepo-nx-enterprise", + "file": "shared/monorepo-nx-enterprise" + } + ] + } + ] + } +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/ng-packagr-lite.md new file mode 100644 index 0000000000..21201d1237 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/ng-packagr-lite.md @@ -0,0 +1,46 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/package.md new file mode 100644 index 0000000000..6e5d6e2e52 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/package.md @@ -0,0 +1,46 @@ +# package + +Build and package an Angular library for publishing + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/webpack-browser.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/webpack-browser.md new file mode 100644 index 0000000000..302b52cb3f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/executors/webpack-browser.md @@ -0,0 +1,326 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/11.4.0/node/api-angular/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/application.md new file mode 100644 index 0000000000..bbe416f9de --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/11.4.0/node/api-angular/generators/downgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/downgrade-module.md new file mode 100644 index 0000000000..83a9b97974 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup 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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma-project.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma-project.md new file mode 100644 index 0000000000..fb87bebaa3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing 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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma.md new file mode 100644 index 0000000000..fa41a5fe46 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/karma.md @@ -0,0 +1,23 @@ +# karma + +Add 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 +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/library.md new file mode 100644 index 0000000000..ab04fd7e4a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/library.md @@ -0,0 +1,185 @@ +# library + +Create 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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Type: `string` + +A directory where the lib is placed + +### enableIvy + +Default: `false` + +Type: `boolean` + +Enable Ivy for library in tsconfig.lib.prod.json. Should not be used with publishable libraries. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/11.4.0/node/api-angular/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/move.md new file mode 100644 index 0000000000..4af4c255fa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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/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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the generator update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/ngrx.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/ngrx.md new file mode 100644 index 0000000000..9d4a0f23dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## 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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/11.4.0/node/api-angular/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/stories.md new file mode 100644 index 0000000000..043fdf1567 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/stories.md @@ -0,0 +1,37 @@ +# 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/angular:stories ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g stories ... --dry-run +``` + +## Options + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-configuration.md new file mode 100644 index 0000000000..073ed1dcd1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a 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/angular:storybook-configuration ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g storybook-configuration ... --dry-run +``` + +## Options + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library/application? + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..9476ba7794 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/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 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/data-access-documents/src/data/11.4.0/node/api-angular/generators/upgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/upgrade-module.md new file mode 100644 index 0000000000..093f05de01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-angular/generators/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add 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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/node/api-cypress/executors/cypress.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-cypress/executors/cypress.md new file mode 100644 index 0000000000..ff3d74242f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-cypress/executors/cypress.md @@ -0,0 +1,126 @@ +# cypress + +Run Cypress e2e tests + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/11.4.0/node/api-express/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-express/generators/application.md new file mode 100644 index 0000000000..c801960e6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-express/generators/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/build.md new file mode 100644 index 0000000000..47ce509dcf --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/build.md @@ -0,0 +1,48 @@ +# build + +Build a Gatsby app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### color + +Default: `true` + +Type: `boolean` + +Enable colored terminal output. + +### graphqlTracing + +Type: `boolean` + +Trace every graphql resolver, may have performance implications. + +### openTracingConfigFile + +Type: `string` + +Tracer configuration file (OpenTracing compatible). + +### prefixPaths + +Type: `boolean` + +Build site with link paths prefixed (set pathPrefix in your config). + +### profile + +Type: `boolean` + +Build site with react profiling. + +### uglify + +Default: `true` + +Type: `boolean` + +Build site without uglifying JS bundles (true by default). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/server.md new file mode 100644 index 0000000000..66b9ddaec1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/executors/server.md @@ -0,0 +1,44 @@ +# server + +Starts server for app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### https + +Default: `false` + +Type: `boolean` + +Serve using HTTPS. + +### open + +Type: `boolean` + +Open the site in your (default) browser for you. + +### port + +Default: `4200` + +Type: `number` + +Port to listen on. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/application.md new file mode 100644 index 0000000000..444d19ee1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/application.md @@ -0,0 +1,89 @@ +# 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/gatsby:application ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g application ... --dry-run +``` + +## Options + +### directory + +Alias(es): d + +Type: `string` + +A directory where the project is placed + +### e2eTestRunner + +Default: `cypress` + +Type: `string` + +Possible values: `cypress`, `none` + +Adds the specified e2e test runner + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files + +### name + +Type: `string` + +### style + +Alias(es): s + +Default: `css` + +Type: `string` + +Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `none` + +The file extension to be used for style files. + +### tags + +Alias(es): t + +Type: `string` + +Add tags to the project (used for linting) + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Adds the specified unit test runner diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/component.md new file mode 100644 index 0000000000..505bd2d0d8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/component.md @@ -0,0 +1,107 @@ +# component + +Create a 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/gatsby: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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/page.md new file mode 100644 index 0000000000..9310106396 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-gatsby/generators/page.md @@ -0,0 +1,107 @@ +# page + +Create a page + +## 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/gatsby:page ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g page ... --dry-run +``` + +### Examples + +Generate a page in the mylib library: + +```bash +nx g page my-page --project=mylib +``` + +Generate a class component in the mylib library: + +```bash +nx g page my-page --project=mylib --classComponent +``` + +## Options + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-jest/executors/jest.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-jest/executors/jest.md new file mode 100644 index 0000000000..356ac69ad8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-jest/executors/jest.md @@ -0,0 +1,222 @@ +# jest + +Run Jest unit tests + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-linter/executors/eslint.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-linter/executors/eslint.md new file mode 100644 index 0000000000..64463a8fa9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-linter/executors/eslint.md @@ -0,0 +1,102 @@ +# eslint + +Run ESLint on a project + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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/data-access-documents/src/data/11.4.0/node/api-linter/executors/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-linter/executors/lint.md new file mode 100644 index 0000000000..0bdeba5142 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-linter/executors/lint.md @@ -0,0 +1,110 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/11.4.0/node/api-nest/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/application.md new file mode 100644 index 0000000000..cca4d44354 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest 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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/node/api-nest/generators/class.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/class.md new file mode 100644 index 0000000000..6e68d6c09b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/class.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/controller.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/controller.md new file mode 100644 index 0000000000..675f120e09 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/controller.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/decorator.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/decorator.md new file mode 100644 index 0000000000..3d78970593 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/decorator.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/filter.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/filter.md new file mode 100644 index 0000000000..ae68bfb9c7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/filter.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/gateway.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/gateway.md new file mode 100644 index 0000000000..158e69e78e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/gateway.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/guard.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/guard.md new file mode 100644 index 0000000000..79030bc77d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/guard.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interceptor.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interceptor.md new file mode 100644 index 0000000000..baf34e7065 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interceptor.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interface.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interface.md new file mode 100644 index 0000000000..5d8e361733 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/interface.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/library.md new file mode 100644 index 0000000000..5e59e4f3c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/library.md @@ -0,0 +1,167 @@ +# library + +Create a new nest 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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/node/api-nest/generators/middleware.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/middleware.md new file mode 100644 index 0000000000..a98c69da25 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/middleware.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/module.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/module.md new file mode 100644 index 0000000000..d6c89ec362 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/module.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/pipe.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/pipe.md new file mode 100644 index 0000000000..3bc792d24f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/pipe.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/provider.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/provider.md new file mode 100644 index 0000000000..546a44396b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/provider.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/resolver.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/resolver.md new file mode 100644 index 0000000000..76cde3741d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/resolver.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/service.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/service.md new file mode 100644 index 0000000000..241519d348 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nest/generators/service.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/build.md new file mode 100644 index 0000000000..6430d70759 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/build.md @@ -0,0 +1,44 @@ +# build + +Build a Next.js app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/export.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/export.md new file mode 100644 index 0000000000..8f9d649dd2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/export.md @@ -0,0 +1,28 @@ +# export + +Export a Next.js app. The exported application is located at dist/$outputPath/exported. + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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/data-access-documents/src/data/11.4.0/node/api-next/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/server.md new file mode 100644 index 0000000000..c32b25a872 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/executors/server.md @@ -0,0 +1,64 @@ +# server + +Serve a Next.js app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/node/api-next/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/application.md new file mode 100644 index 0000000000..7fe8a93eed --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/application.md @@ -0,0 +1,131 @@ +# 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. + +### 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) + +### 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. + +### 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/data-access-documents/src/data/11.4.0/node/api-next/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/component.md new file mode 100644 index 0000000000..bb6cffb91e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/component.md @@ -0,0 +1,107 @@ +# 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/node/api-next/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/page.md new file mode 100644 index 0000000000..82ca21954e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-next/generators/page.md @@ -0,0 +1,107 @@ +# 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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/node/api-node/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/build.md new file mode 100644 index 0000000000..24482b310f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/build.md @@ -0,0 +1,162 @@ +# build + +Build a Node application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/execute.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/execute.md new file mode 100644 index 0000000000..fb7bcfd2cd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/execute.md @@ -0,0 +1,64 @@ +# execute + +Execute a Node application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/11.4.0/node/api-node/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/package.md new file mode 100644 index 0000000000..cd2b34a691 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/executors/package.md @@ -0,0 +1,78 @@ +# package + +Package a Node library + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/node/api-node/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/generators/application.md new file mode 100644 index 0000000000..5ed7f18cd4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/generators/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/node/api-node/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/generators/library.md new file mode 100644 index 0000000000..864624be6d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-node/generators/library.md @@ -0,0 +1,167 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/node/api-nx-plugin/executors/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/executors/e2e.md new file mode 100644 index 0000000000..7ccb9278ba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/executors/e2e.md @@ -0,0 +1,26 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/executor.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/executor.md new file mode 100644 index 0000000000..aed9587869 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/executor.md @@ -0,0 +1,65 @@ +# 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 + +### description + +Alias(es): d + +Type: `string` + +Executor description + +### name + +Type: `string` + +Executor name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/generator.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/generator.md new file mode 100644 index 0000000000..64d2686a74 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/generator.md @@ -0,0 +1,65 @@ +# 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 + +### description + +Alias(es): d + +Type: `string` + +Generator description + +### name + +Type: `string` + +Generator name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/migration.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/migration.md new file mode 100644 index 0000000000..82867640a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/migration.md @@ -0,0 +1,73 @@ +# 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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/plugin.md new file mode 100644 index 0000000000..f7bce6c1ba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-nx-plugin/generators/plugin.md @@ -0,0 +1,97 @@ +# 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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/node/api-react/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/application.md new file mode 100644 index 0000000000..8bb109275c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/application.md @@ -0,0 +1,173 @@ +# 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/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. + +### 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. + +### 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. + +### 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). + +### 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/data-access-documents/src/data/11.4.0/node/api-react/generators/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component-cypress-spec.md new file mode 100644 index 0000000000..58b52f635a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component-story.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component-story.md new file mode 100644 index 0000000000..35ef6ced9c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component-story.md @@ -0,0 +1,37 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component.md new file mode 100644 index 0000000000..2633a1c1e9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/component.md @@ -0,0 +1,145 @@ +# component + +Create a 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 + +### 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. + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/node/api-react/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/library.md new file mode 100644 index 0000000000..fe6358933e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/library.md @@ -0,0 +1,181 @@ +# 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/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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### 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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/node/api-react/generators/redux.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/redux.md new file mode 100644 index 0000000000..cda1e636d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/redux.md @@ -0,0 +1,67 @@ +# 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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/11.4.0/node/api-react/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/stories.md new file mode 100644 index 0000000000..8189aab8a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/stories.md @@ -0,0 +1,45 @@ +# 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 + +### 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. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-configuration.md new file mode 100644 index 0000000000..17f5719530 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..6253cf44e8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-react/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/data-access-documents/src/data/11.4.0/node/api-storybook/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/executors/build.md new file mode 100644 index 0000000000..2947ef1427 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/executors/build.md @@ -0,0 +1,44 @@ +# build + +Build Storybook + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### 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. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/executors/storybook.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/executors/storybook.md new file mode 100644 index 0000000000..a5e75e11a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/executors/storybook.md @@ -0,0 +1,88 @@ +# storybook + +Serve Storybook + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### 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. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/configuration.md new file mode 100644 index 0000000000..ecd1fe6262 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/configuration.md @@ -0,0 +1,63 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### 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` + +Library or application name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/cypress-project.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/cypress-project.md new file mode 100644 index 0000000000..8b70e27fd3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/cypress-project.md @@ -0,0 +1,49 @@ +# 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 + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..4054001fcf --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-storybook/generators/migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/data-access-documents/src/data/11.4.0/node/api-web/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/build.md new file mode 100644 index 0000000000..3dc4ddc8b6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/build.md @@ -0,0 +1,252 @@ +# build + +Build a application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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. + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/node/api-web/executors/dev-server.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/dev-server.md new file mode 100644 index 0000000000..00bb971158 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/dev-server.md @@ -0,0 +1,106 @@ +# dev-server + +Serve a web application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/node/api-web/executors/file-server.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/file-server.md new file mode 100644 index 0000000000..5a0c2c1c76 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/file-server.md @@ -0,0 +1,78 @@ +# file-server + +Serve a web application from a folder + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +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/data-access-documents/src/data/11.4.0/node/api-web/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/package.md new file mode 100644 index 0000000000..f76ae8440a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/executors/package.md @@ -0,0 +1,122 @@ +# package + +Package a library + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### deleteOutputPath + +Default: `true` + +Type: `boolean` + +Delete the output path before building. + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/11.4.0/node/api-web/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/generators/application.md new file mode 100644 index 0000000000..914d89a1c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-web/generators/application.md @@ -0,0 +1,103 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-commands.md new file mode 100644 index 0000000000..047411d0d0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-commands.md @@ -0,0 +1,220 @@ +# run-commands + +Run any custom commands with Nx + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-script.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-script.md new file mode 100644 index 0000000000..17df3dbf53 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/executors/run-script.md @@ -0,0 +1,14 @@ +# run-script + +Run an npm script using Nx + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/node/getting-started/cli-overview#running-tasks. + +## Properties + +### script + +Type: `string` + +Script to run in child process diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/library.md new file mode 100644 index 0000000000..1f0f79e2a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/library.md @@ -0,0 +1,141 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### strict + +Default: `false` + +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/data-access-documents/src/data/11.4.0/node/api-workspace/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/move.md new file mode 100644 index 0000000000..723a022898 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/move.md @@ -0,0 +1,75 @@ +# 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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### 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/data-access-documents/src/data/11.4.0/node/api-workspace/generators/remove.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/remove.md new file mode 100644 index 0000000000..a83d277938 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/remove.md @@ -0,0 +1,71 @@ +# 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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/run-commands.md new file mode 100644 index 0000000000..fb24979f18 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/run-commands.md @@ -0,0 +1,73 @@ +# 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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### envFile + +Type: `string` + +Env files to be loaded before executing the commands + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/workspace-generator.md new file mode 100644 index 0000000000..7d95e3eef7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/api-workspace/generators/workspace-generator.md @@ -0,0 +1,43 @@ +# 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/data-access-documents/src/data/11.4.0/node/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/node/cli/affected-build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-build.md new file mode 100644 index 0000000000..87dbc13855 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-build.md @@ -0,0 +1,133 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/node/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-e2e.md new file mode 100644 index 0000000000..13992dcca8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-e2e.md @@ -0,0 +1,121 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/node/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/node/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-lint.md new file mode 100644 index 0000000000..93c30beaa9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-lint.md @@ -0,0 +1,121 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/node/cli/affected-test.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-test.md new file mode 100644 index 0000000000..7339dc151c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected-test.md @@ -0,0 +1,121 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/node/cli/affected.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected.md new file mode 100644 index 0000000000..5b4b792fad --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/affected.md @@ -0,0 +1,143 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/node/cli/build.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/11.4.0/node/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/cli/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/e2e.md new file mode 100644 index 0000000000..279449cf40 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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/data-access-documents/src/data/11.4.0/node/cli/format-check.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/node/cli/format-write.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/node/cli/generate.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/generate.md new file mode 100644 index 0000000000..0fa39dc3f6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/generate.md @@ -0,0 +1,93 @@ +# 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 the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/node/cli/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/11.4.0/node/cli/list.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/list.md new file mode 100644 index 0000000000..312250e849 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/cli/migrate.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/node/cli/print-affected.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/11.4.0/node/cli/report.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run-many.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run-many.md new file mode 100644 index 0000000000..0a247289e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run-many.md @@ -0,0 +1,97 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/node/cli/serve.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/11.4.0/node/cli/test.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/11.4.0/node/cli/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/workspace-generator.md new file mode 100644 index 0000000000..dca864f7aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/workspace-generator.md @@ -0,0 +1,29 @@ +# workspace-generator + +Runs a workspace generator from the tools/generators directory + +## Usage + +```bash +nx workspace-generator +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/node/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/executors.json b/nx-dev/data-access-documents/src/data/11.4.0/node/executors.json new file mode 100644 index 0000000000..ded073647f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/executors.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/generators.json b/nx-dev/data-access-documents/src/data/11.4.0/node/generators.json new file mode 100644 index 0000000000..46a738dc38 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/generators.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "nest", + "next", + "node", + "nx-plugin", + "react", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/getting-started.md b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/getting-started.md new file mode 100644 index 0000000000..2a7c106a63 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/getting-started.md @@ -0,0 +1,36 @@ +# Getting Started + +Nx is a suite of powerful, extensible dev tools that help you develop, test, build, and scale Node applications. + +## Create Nx Workspace + +Creating an Nx workspace is easy. Run the following command to set up an Nx workspace with an NestJS app in it. + +```bash +npx create-nx-workspace --preset=nest +``` + +To create an Nx workspace with an Express app run: + +```bash +npx create-nx-workspace --preset=empty +``` + +cd into the folder and run: + +``` +npm i @nrwl/express +npx nx g @nrwl/express:app myapp +``` + +## Learn Nx Fundamentals + +- [Interactive Nx Tutorial (with videos)](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) + +## Dive Deep + +- [Nx CLI](/{{framework}}/getting-started/cli-overview) +- [Configuration Files](/{{framework}}/getting-started/configuration) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/resources.md b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/resources.md new file mode 100644 index 0000000000..ab428a04c8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/getting-started/resources.md @@ -0,0 +1,83 @@ +# Resources + +## 45-Minute Walkthrough + + + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## Resources + +### Highlights + +- [Nrwl Talks, Presentations, and Podcasts playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dHHWx4JIORwfnEajRv6FG5m) + +- [Nx Blog Posts](https://blog.nrwl.io/nx/home) + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [Nx Office Hours playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dE8KLQ5zd3fQwu_yQHjTmR5) + +### Podcasts and Shows + +- [Nx Plugins - ngHouston](https://youtu.be/bydqr-Yxsu8), Wes Grimes and Jon Cammisuli (April 8 2020) + +- [Apollo GQL, Angular & Nx - ngHouston](https://youtu.be/bydqr-Yxsu8), Philip Fulcher (Feb 26, 2020) + +- [Teach Me Anything - With Isaac Mann from Nrwl](https://youtu.be/WRmj4JwfoMs), Isaac Mann (Jan 9, 2020) + +- [Sneak Peek of New Nx Workspace Course - ngHouston](https://www.youtube.com/watch?v=uLbA4f2SINE&feature=youtu.be), Isaac Mann (Nov 27, 2019) + +- [React Roundup: Nx and Monorepos](https://player.fm/series/react-round-up/rru-081-nx-and-monorepos-with-jeffrey-cross-and-victor-savkin), Victor Savkin (Oct 1, 2019) + +- [Nx and Angular CLI - Adventures in Angular](https://devchat.tv/adv-in-angular/aia-254-nx-and-angular-cli-with-brandon-roberts/), Brandon Roberts (Aug 27th 2019) + +- [ngHouston: NX Demo](https://www.youtube.com/watch?v=E_UlU2Yv4G0) (Dec 7, 2017) + +- [ngAir 140: Nx for Enterprise Angular Development](https://www.youtube.com/watch?v=qYNiOKDno_I), Victor Savkin (Dec 12, 2017) + +### Nx Demo & Tutorial Videos + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (Angular)](https://youtu.be/h5FIGDn5YM0) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Nx Console - A Must-Have Visual Studio Code Extension for Angular Developers](https://youtu.be/IIetmfgozgI) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +### Books amd Blogs + +- [Angular Enterprise Monorepo Patterns Book (free)](https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book?utm_campaign=Book%3A%20Monorepo%20Patterns%2C%20Jan%202019&utm_source=Github&utm_medium=Banner%20Ad) + +* [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +* [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +- [Tiny Angular application projects in Nx workspaces](https://indepth.dev/tiny-angular-application-projects-in-nx-workspaces/#peer-reviewers--30/) (March 2020) + +### Misc + +- [xplat - Cross-platform tools for Nx workspaces](https://nstudio.io/xplat/) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/cli-overview.md new file mode 100644 index 0000000000..89da92788a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/cli-overview.md @@ -0,0 +1,265 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/node`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called generators. Generators provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/node:application myapp +``` + +The `@nrwl/node` package contains a collection of generators, with `application` being the one used in this example. The Nx CLI applies the generator to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the generator. + +```sh +nx generate @nrwl/node:application myapp --style=scss +``` + +You can preview the changes a generator makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the generator. + +**Generate command:** + +`nx generate` runs generators to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[generator-name] [options]` + Example: `nx generate @nrwl/node:library my-node-lib` + +## Running Tasks + +The Nx CLI uses executors to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +You can configure the executors in `workspace.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "targets": { + "serve": { + "executor": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` executor, and the `test` target uses `@nrwl/jest:jest`. Every target uses an executor which actually runs this target. So targets are analogous to typed npm scripts, and executors are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # production configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any executors you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the executor. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the executor. + +```sh +nx affected --target=build --prod +``` + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/guides/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/configuration.md new file mode 100644 index 0000000000..ae9a719f02 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/configuration.md @@ -0,0 +1,373 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## workspace.json + +The `workspace.json` configuration file contains information about the targets and generators. Let's look at the following example: + +```json +{ + "version": 2, + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "targets": { + "build": { + "executor": "@nrwl/node:build", + "outputs": ["dist/apps/myapp"], + "options": { + "outputPath": "dist/packages/myapp", + "main": "packages/myapp/src/main.ts", + "tsConfig": "packages/myapp/tsconfig.app.json", + "assets": ["packages/myapp/src/assets"] + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "executor": "@nrwl/node:execute", + "options": { + "buildTarget": "myapp:build" + } + }, + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "targets": { + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + }, + "build": { + "executor": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/node" + }, + "generators": { + "@nrwl/node:library": { + "js": true + } + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "targets": {} + } +} +``` + +- `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'. +- `targets` configures all the targets which define what tasks you can run against the library. + +### Targets + +Let's look at the simple target: + +```json +{ + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js" + } + } +} +``` + +**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 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" +} +``` + +**Outputs** + +The `outputs` property lists the folders the executor will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "executor": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "executor": "@nrwl/node:package", + "options": { + "outputPath": "dist/libs/mylib", + "tsConfig": "libs/mylib/tsconfig.lib.json", + "packageJson": "libs/mylib/package.json", + "main": "libs/mylib/src/index.ts", + "assets": ["libs/mylib/*.md"] + } + }, + "configurations": { + "production": { + "packageJson": "libs/mylib/package.prod.json" + } + } +} +``` + +You can select a configuration like this: `nx build mylib --configuration=production` or `nx run mylib:build:configuration=production`. + +The following show how the executor options get constructed: + +```bash +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. + +### Generators + +You can configure default generator options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. + +```json +{ + "generators": { + "@nrwl/node:library": { + "buildable": true + } + } +} +``` + +You can also do it on the project level: + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "generators": { + "@nrwl/node:lib": { + "moreOptions": true + } + }, + "targets": {} + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/node:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/node" + } +} +``` + +### Version + +When the `version` of `workspace.json` is set to 2, `targets`, `generators` and `executor` properties are used instead of the version 1 properties `architect`, `schematics` and `builder`. + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "workspace.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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 dependencies between shared files and projects 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` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/guides/storybook-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/storybook-plugin.md new file mode 100644 index 0000000000..1236281880 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/guides/storybook-plugin.md @@ -0,0 +1,10 @@ +# Storybook + +![Storybook logo](/shared/storybook-logo.png) + +Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. + +## Links to Further Instructions + +- [Angular](/angular/storybook/overview) +- [React](/react/storybook/overview) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/01-create-application.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/01-create-application.md new file mode 100644 index 0000000000..1ac6a5dd01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/01-create-application.md @@ -0,0 +1,131 @@ +# Node Nx Tutorial - Step 1: Create Application + +## Nx.dev Tutorial | Node | Step 1: Create Application + + + +In this tutorial you will use Nx to build a server application out of common libraries using modern technologies. + +## Create a New Workspace + +**Start by creating a new workspace.** + +```bash +npx create-nx-workspace@latest +``` + +You will then receive the following prompts in your command line: + +``` +? Workspace name (e.g., org name) myorg +? What to create in the new workspace nest +? Application name todos +``` + +```treeview +myorg/ +├── README.md +├── apps/ +│   └── todos/ +│   ├── jest.config.js +│   ├── src/ +│   │   ├── app/ +│   │   │   ├── app.controller.spec.ts +│   │   │   ├── app.controller.ts +│   │   │   ├── app.module.ts +│   │   │   ├── app.service.spec.ts +│   │   │   └── app.service.ts +│   │   ├── assets/ +│   │   ├── environments/ +│   │   │   ├── environment.prod.ts +│   │   │   └── environment.ts +│   │   └── main.ts +│   ├── tsconfig.app.json +│   ├── tsconfig.json +│   └── tsconfig.spec.json +├── tools/ +│   ├── generators +│   └── tsconfig.tools.json +├── jest.config.js +├── libs +├── nx.json +├── package.json +├── tsconfig.base.json +└── workspace.json +``` + +The generate command added one project to our workspace: + +- A Nest application + +## Note on the Nx CLI + +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: + +```shell script +npm install -g nx +``` + +or + +```shell script +yarn global add nx +``` + +Or you can prepend every command with `npm run`: + +```bash +npm run nx -- serve todos +``` + +or + +```bash +yarn nx serve todos +``` + +## Workspace.json, Targets, Builders + +You configure your workspaces in `workspace.json`. This file contains the workspace projects with their architect targets. For instance, `todos` has the `build`, `serve`, `lint`, and `test` targets. This means that you can run `nx build todos`, `nx serve todos`, etc.. + +Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +**Why not use shell scripts and npm scripts directly?** + +There are a lot of advantages to providing additional metadata to the build tool. For instance, you can introspect targets. `nx serve todos --help` results in: + +```shell script +nx run todos:serve [options,...] + +Options: + --buildTarget The target to run to build you the app + --waitUntilTargets The targets to run to before starting the node app (default: ) + --host The host to inspect the process on (default: localhost) + --port The port to inspect the process on. Setting port to 0 will assign random free ports to all forked processes. + --watch Run build when files change (default: true) + --inspect Ensures the app is starting with debugging (default: inspect) + --runtimeArgs Extra args passed to the node process (default: ) + --args Extra args when starting the app (default: ) + --help Show available options for project target. +``` + +It helps with good editor integration (see [VSCode Support](https://nx.dev/node/getting-started/console)). + +But, most importantly, it provides a holistic dev experience regardless of the tools used, and enables advanced build features like distributed computation caching and distributed builds). + +## Serve the newly created application + +Now that the application is set up, run it locally via: + +```shell script +nx serve todos +``` + +!!!!! +Open http://localhost:3333/api in the browser. What do you see? +!!!!! +Page saying "{"message":"Welcome to todos!"}" +Page saying "This is Nest app built with Nx!" +404 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/02-display-todos.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/02-display-todos.md new file mode 100644 index 0000000000..90d51f190b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/02-display-todos.md @@ -0,0 +1,156 @@ +# Node Nx Tutorial - Step 2: Display todos + +## Nx.dev Tutorial | Node | Step 2: Display Todos + + + +Great! We now have a server application set up to show some data when going to the `/api` route. + +Next, we're going to add a new service, and set up some server side templates. + +## Creating a todos service + +With Nx, we have the ability to scaffold out new code for our application. Let's create a Todos service and populate some todos! + +**Run `nx generate @nrwl/nest:service todo --project todos --directory app` to generate our new service** + +```shell script +$ nx generate @nrwl/nest:service todo --project todos --directory app +CREATE apps/todos/src/app/todo/todo.service.spec.ts (453 bytes) +CREATE apps/todos/src/app/todo/todo.service.ts (89 bytes) +UPDATE apps/todos/src/app/app.module.ts (318 bytes) +``` + +> Services are not the only things that the `@nrwl/nest` plugin can create. Run `nx list @nrwl/nest` to see other capabilities that the plugin provides. + +Open the newly created file in `apps/todos/src/app/todo/todo.service.ts` and paste the following code: + +```typescript +import { Injectable } from '@nestjs/common'; + +export type Todo = { + message: string; + done: boolean; +}; + +const todos: Todo[] = [ + { message: 'Take out trash', done: false }, + { message: 'Continue using Nx', done: false }, +]; + +@Injectable() +export class TodosService { + getTodos(): Todo[] { + return todos; + } +} +``` + +> Usually services should call some kind of data source (like a database or even a file) but for our tutorial, we'll just populate todos manually. + +We now have our Todos service ready! + +## Install template engine + +In order to render some views, we'll need to install a template engine: + +```shell script +yarn add hbs +``` + +or + +```shell script +npm install --save hbs +``` + +Once the installation process is complete, we need to configure the `main.ts` file with the following code: + +```typescript +import { Logger } from '@nestjs/common'; +import { NestFactory } from '@nestjs/core'; +import { NestExpressApplication } from '@nestjs/platform-express'; +import { join } from 'path'; + +import { AppModule } from './app/app.module'; + +async function bootstrap() { + const app = await NestFactory.create(AppModule); + + app.setBaseViewsDir(join(__dirname, 'assets', 'views')); + app.setViewEngine('hbs'); + + const port = process.env.PORT || 3333; + await app.listen(port, () => { + Logger.log('Listening at http://localhost:' + port); + }); +} + +bootstrap(); +``` + +We added configuration for setting up the view engine, and removed the `globalPrefix` option. + +## Template rendering + +Under the `assets` directory of the todo's project, we'll create a `views` directory with an `index.hbs` file inside with the following content: + +```handlebars + + + + + App + + + +
    + {{#each todos}} +
  • {{message}}
    • + {{/each}} +
+ + +``` + +Next, we'll update the `app.controller.ts` file with the following: + +```typescript +import { Controller, Get, Render } from '@nestjs/common'; + +import { AppService } from './app.service'; +import { TodosService } from './todos/todos.service'; + +@Controller() +export class AppController { + constructor( + private readonly appService: AppService, + private todosService: TodosService + ) {} + + @Get('api') + getData() { + return this.todosService.getTodos(); + } + + @Get() + @Render('index') + root() { + return { + todos: this.getData(), + }; + } +} +``` + +We changed the `@Get` decorator for the `getData` function to point to the `api` route. We also changed this to call the `todosService.getTodos()` method. \ +Then we added the `root` function which renders the `index` file from our `views` directory. + +> The serve process should still be running. If it isn't, restart the process with `nx serve todos` + +!!!!! +Open http://localhost:3333 in the browser. What do you see? +!!!!! +Page saying "Welcome to todos!" +Page saying "{"message":"Welcome to todos!"}" +404 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/03-share-code.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/03-share-code.md new file mode 100644 index 0000000000..f914968b80 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/03-share-code.md @@ -0,0 +1,82 @@ +# Node Nx Tutorial - Step 3: Share Code + +## Nx.dev Tutorial | Node | Step 3: Share Code + + + +Awesome! The application is working as expected! + +Next, let's work on refactoring a bit. What we're planning to do is move the `Todo` type to it's own library. This is important if we want to share the type between multiple applications, without having to duplicate the same type everywhere. + +**Run the following generator to create a library:** + +```bash +nx g @nrwl/workspace:lib data +``` + +The result should look like this: + +```treeview +myorg/ +├── apps/ +│   └── todos/ +├── libs/ +│   └── data/ +│      ├── src/ +│      │   ├── lib/ +│ │ │ └── data.ts +│      │   └── index.ts +│      ├── jest.config.js +│      ├── tsconfig.lib.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.base.json +``` + +**Copy the type into `libs/data/src/lib/data.ts`.** + +```typescript +export type Todo = { + message: string; + done: boolean; +}; +``` + +### 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 recognised. This needs to be done **every time a new workspace library is added**. + +Use the command pallette with a `*.ts` file open and choose `Restart TS Server`. + +## Refactor the Todos Service + +**Now update `apps/todos/src/app/todos/todos.service.ts` to import the type:** + +```typescript +import { Injectable } from '@nestjs/common'; +import { Todo } from '@myorg/data'; + +const todos: Todo[] = [ + { message: 'Take out trash', done: false }, + { message: 'Continue using Nx', done: false }, +]; + +@Injectable() +export class TodosService { + getTodos(): Todo[] { + return todos; + } +} +``` + +Every time you add a new library, you have to restart `nx serve`. **So restart `nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between Nx applications and libraries +Between Nx applications +Between Nx libraries diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/04-create-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/04-create-libs.md new file mode 100644 index 0000000000..535c9956d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/04-create-libs.md @@ -0,0 +1,95 @@ +# Node Nx Tutorial - Step 4: Create Libraries + +## Nx.dev Tutorial | Node | Step 4: Create Libraries + + + +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. + +## Controller Libraries + +To illustrate how useful libraries can be, create a new Auth library with a controller. + +Run + +```bash +nx g @nrwl/nest:lib auth --controller +``` + +> We added the `--controller` flag here to generate a controller along with the library scaffolding. + +You should see the following: + +```treeview +myorg/ +├── apps/ +│ └── todos/ +├── libs/ +│ ├── auth/ +│ │ ├── jest.config.js +│ │ ├── src/ +│ │ │ ├── index.ts +│ │ │ └── lib/ +│ │ │ ├── auth.controller.spec.ts +│ │ │ ├── auth.controller.ts +│ │ │ └── auth.module.ts +│ │ ├── tsconfig.json +│ │ ├── tsconfig.lib.json +│ │ └── tsconfig.spec.json +│ └── data/ +├── tools/ +├── nx.json +├── package.json +├── tsconfig.base.json +└── workspace.json +``` + +Modify the `libs/auth/src/lib/auth.controller.ts` file like this: + +```typescript +import { Controller, Get } from '@nestjs/common'; + +@Controller('auth') +export class AuthController { + @Get() + auth() { + return { + authenticated: true, + }; + } +} +``` + +> In code destined for production, we would actually have a proper authentication check here. + +## Use the new Library + +**Now import `AuthModule` into `apps/todos/src/app/app.module.ts`.** + +```typescript +import { Module } from '@nestjs/common'; + +import { AppController } from './app.controller'; +import { AppService } from './app.service'; +import { TodosService } from './todos/todos.service'; +import { AuthModule } from '@myorg/auth'; + +@Module({ + imports: [AuthModule], + controllers: [AppController], + providers: [AppService, TodosService], +}) +export class AppModule {} +``` + +**Restart `nx serve todos` then go to http://localhost:3333/auth. You should see `{ authenticated: true }`** + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +workspace.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/05-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/05-dep-graph.md new file mode 100644 index 0000000000..78f8c7c308 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/05-dep-graph.md @@ -0,0 +1,18 @@ +# Node Nx Tutorial - Step 5: Dep Graph + +## Nx.dev Tutorial | Node | Step 5: Dep Graph + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "nx dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/06-computation-caching.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/06-computation-caching.md new file mode 100644 index 0000000000..7e2523ce33 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/06-computation-caching.md @@ -0,0 +1,82 @@ +# Node Nx Tutorial - Step 6: Computation Caching + +## Nx.dev Tutorial | Node | Step 6: Computation Caching + + + +Nx has built-in computation caching, which drastically improves the performance of the commands. + +**To see it in action, run `nx build todos`:** + +```bash +> nx run todos:build +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: 51f23143c450a9f931a7 +Built at: 09/04/2020 4:03:20 PM +Entrypoint main = main.js main.js.map +chunk {main} main.js, main.js.map (main) 4.17 KiB [entry] [rendered] +``` + +**Now, run `nx build todos` again, and you will see the results appearing instantly:** + +```bash +> nx run todos:build + +> NX NOTE Cached Output: + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: 51f23143c450a9f931a7 +Built at: 09/04/2020 4:03:20 PM +Entrypoint main = main.js main.js.map +chunk {main} main.js, main.js.map (main) 4.17 KiB [entry] [rendered] +``` + +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. + +## --with-deps + +Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> nx run data:lint + +Linting "data"... + +All files pass linting. + + +> nx run auth:lint + +Linting "auth"... + +All files pass linting. + + +> nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `nx lint auth --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 1 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/07-test-affected-projects.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/07-test-affected-projects.md new file mode 100644 index 0000000000..d28688609d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/07-test-affected-projects.md @@ -0,0 +1,81 @@ +# Node Nx Tutorial - Step 7: Test Affected Projects + +## Nx.dev Tutorial | Node | Step 6: Computation Caching + + + +In addition to supporting computation caching, Nx can scale your development by doing code change analysis to see what apps or libraries are affected by a particular pull request. + +**Commit all the changes in the repo**: + +```bash +git add . +git commit -am 'init' +git checkout -b testbranch +``` + +**Open `libs/auth/src/lib/auth.controller.ts` and change the controller:** + +```typescript +import { Body, Controller, Get, Post } from '@nestjs/common'; + +@Controller('auth') +export class AuthController { + @Get() + auth() { + return { + authenticated: true, + }; + } + + @Post() + authenticate(@Body() postData: { username: string; password: string }) { + const { username, password } = postData; + // check the database + console.log(username, password); + } +} +``` + +**Run `nx affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps are affected by this change. + +**Run `nx affected:libs`**, and you should see `auth` 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 `nx affected:test` to retest only the projects affected by the change.** + +As you can see, since we updated the code, without updating the tests, the unit tests failed. + +```bash +> NX Running target test for projects: + + - auth + - todos + +... + + Failed projects: + + - todos +``` + +Note that Nx only tried to retest `auth` and `todos`. It didn't retest `data` because there is no way that library could be affected by the changes in this branch. + +## Affected:\* + +You can run any target against the affected projects in the graph like this: + +```bash +# The following are equivalent +nx affected --target=build +nx affected:build +``` + +!!!!! +Run "nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects with "invalid" were run +An error message saying that the "invalid" target is invalid diff --git a/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/08-summary.md b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/08-summary.md new file mode 100644 index 0000000000..6ef5520a5a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/node/tutorial/08-summary.md @@ -0,0 +1,18 @@ +# Node Nx Tutorial - Step 8: Summary + +In this tutorial you: + +- Built a full Node application with an API and server side rendered pages +- Shared code +- Created a Controller library +- Used Nx dep graph capabilities 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](/{{framework}}/getting-started/cli-overview) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/ng-packagr-lite.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/ng-packagr-lite.md new file mode 100644 index 0000000000..d25e311dac --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/ng-packagr-lite.md @@ -0,0 +1,46 @@ +# ng-packagr-lite + +Build an Angular library for incremental building + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/package.md new file mode 100644 index 0000000000..11fd6fd02c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/package.md @@ -0,0 +1,46 @@ +# package + +Build and package an Angular library for publishing + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### project + +Type: `string` + +The file path for the ng-packagr configuration file, relative to the current workspace. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### updateBuildableProjectDepsInPackageJson + +Default: `true` + +Type: `boolean` + +Update buildable project dependencies in package.json + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/webpack-browser.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/webpack-browser.md new file mode 100644 index 0000000000..dbc31886c9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/executors/webpack-browser.md @@ -0,0 +1,326 @@ +# webpack-browser + +Angular browser builder that supports incremental builds + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### allowedCommonJsDependencies + +Type: `array` + +A list of CommonJS packages that are allowed to be used without a build time warning. + +### aot + +Default: `false` + +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: `false` + +Type: `boolean` + +Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. + +### commonChunk + +Default: `true` + +Type: `boolean` + +Use a separate 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` + +URL where files will be deployed. + +### experimentalRollupPass + +Default: `false` + +Type: `boolean` + +Concatenate modules with Rollup before bundling them with Webpack. + +### extractCss + +Default: `false` + +Type: `boolean` + +Extract css from global styles into css files instead of js ones. + +### extractLicenses + +Default: `false` + +Type: `boolean` + +Extract all licenses in a separate file. + +### fileReplacements + +Type: `array` + +Replace compilation source files with other compilation source files in the build. + +### forkTypeChecker + +Default: `true` + +Type: `boolean` + +Run the TypeScript type checker in a forked process. + +### i18nFile + +Type: `string` + +Localization file to use for i18n. + +### i18nFormat + +Type: `string` + +Format of the localization file specified with --i18n-file. + +### i18nLocale + +Type: `string` + +Locale to use for i18n. + +### i18nMissingTranslation + +Default: `warning` + +Type: `string` + +Possible values: `warning`, `error`, `ignore` + +How to handle missing translations for i18n. + +### index + +Type: `string` + +Configures the generation of the application's HTML index. + +### lazyModules + +Type: `array` + +List of additional NgModule files that will be lazy loaded. Lazy router modules will be discovered automatically. + +### localize + +Type: `boolean | boolean[] ` + +### main + +Type: `string` + +The full path for the main entry point to the app, relative to the current workspace. + +### namedChunks + +Default: `true` + +Type: `boolean` + +Use file name for lazy loaded chunks. + +### ngswConfigPath + +Type: `string` + +Path to ngsw-config.json. + +### optimization + +Default: `false` + +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 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. + +### 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 + +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: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### 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. + +### tsConfig + +Type: `string` + +The full path for the TypeScript configuration file, relative to the current workspace. + +### vendorChunk + +Default: `true` + +Type: `boolean` + +Use a separate bundle containing only vendor libraries. + +### 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/data-access-documents/src/data/11.4.0/react/api-angular/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/application.md new file mode 100644 index 0000000000..bbe416f9de --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/application.md @@ -0,0 +1,179 @@ +# application + +Create 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 + +### 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 + +### enableIvy + +Default: `true` + +Type: `boolean` + +Create a new app that uses the Ivy rendering engine. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### prefix + +Alias(es): p + +Type: `string` + +The prefix to apply to generated selectors. + +### routing + +Default: `false` + +Type: `boolean` + +Generates a routing module. + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates an application with stricter type checking and build optimization options. + +### 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: `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/data-access-documents/src/data/11.4.0/react/api-angular/generators/downgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/downgrade-module.md new file mode 100644 index 0000000000..83a9b97974 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/downgrade-module.md @@ -0,0 +1,59 @@ +# downgrade-module + +Setup 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 + +### angularJsImport + +Type: `string` + +Import expression of the AngularJS application (e.g., --angularJsImport=some_node_module/my_app). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma-project.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma-project.md new file mode 100644 index 0000000000..fb87bebaa3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma-project.md @@ -0,0 +1,31 @@ +# karma-project + +Add karma testing 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 + +Type: `string` + +The name of the project. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma.md new file mode 100644 index 0000000000..fa41a5fe46 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/karma.md @@ -0,0 +1,23 @@ +# karma + +Add 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 +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/library.md new file mode 100644 index 0000000000..ab04fd7e4a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/library.md @@ -0,0 +1,185 @@ +# library + +Create 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 + +### addModuleSpec + +Default: `false` + +Type: `boolean` + +Add a module spec file. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Type: `string` + +A directory where the lib is placed + +### enableIvy + +Default: `false` + +Type: `boolean` + +Enable Ivy for library in tsconfig.lib.prod.json. Should not be used with publishable libraries. + +### 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: `tslint`, `eslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### 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. + +### simpleModuleName + +Default: `false` + +Type: `boolean` + +Keep the module name simple (when using --directory) + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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. + +### strict + +Default: `false` + +Type: `boolean` + +Creates a library with stricter type checking and build optimization options. + +### 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 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/data-access-documents/src/data/11.4.0/react/api-angular/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/move.md new file mode 100644 index 0000000000..4af4c255fa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/move.md @@ -0,0 +1,65 @@ +# move + +Move an Angular 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/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 + +Type: `string` + +The folder to move the Angular project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the Angular project to move + +### updateImportPath + +Default: `true` + +Type: `boolean` + +Should the generator update the import path to reflect the new location? diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/ngrx.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/ngrx.md new file mode 100644 index 0000000000..9d4a0f23dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/ngrx.md @@ -0,0 +1,135 @@ +# ngrx + +Add an ngrx config to a project + +## 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 + +### 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. + +### module + +Type: `string` + +The path to NgModule where the feature state will be registered. The host directory will create/use the new state directory. + +### name + +Type: `string` + +Name of the NgRx feature state, such as "products" or "users"). Recommended to use the plural form of the name. + +### onlyAddFiles + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `skipImport`. Only add new NgRx files, without changing the module file (e.g., --onlyAddFiles). + +### onlyEmptyRoot + +Default: `false` + +Type: `boolean` + +**Deprecated**, use `minimal`. Do not generate any files. Only generate StoreModule.forRoot and EffectsModule.forRoot (e.g., --onlyEmptyRoot). + +### root + +Default: `false` + +Type: `boolean` + +Setup root or feature state management with NgRx. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting of generated 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/data-access-documents/src/data/11.4.0/react/api-angular/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/stories.md new file mode 100644 index 0000000000..043fdf1567 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/stories.md @@ -0,0 +1,37 @@ +# 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/angular:stories ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g stories ... --dry-run +``` + +## Options + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-configuration.md new file mode 100644 index 0000000000..073ed1dcd1 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-configuration.md @@ -0,0 +1,59 @@ +# storybook-configuration + +Create stories/specs for all components declared in a 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/angular:storybook-configuration ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g storybook-configuration ... --dry-run +``` + +## Options + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library/application? + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..9476ba7794 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/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 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/data-access-documents/src/data/11.4.0/react/api-angular/generators/upgrade-module.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/upgrade-module.md new file mode 100644 index 0000000000..093f05de01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-angular/generators/upgrade-module.md @@ -0,0 +1,73 @@ +# upgrade-module + +Add 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 + +### 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). + +### name + +Type: `string` + +The name of the main AngularJS module. + +### project + +Type: `string` + +The name of the project + +### 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/data-access-documents/src/data/11.4.0/react/api-cypress/executors/cypress.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-cypress/executors/cypress.md new file mode 100644 index 0000000000..14cee12bed --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-cypress/executors/cypress.md @@ -0,0 +1,126 @@ +# cypress + +Run Cypress e2e tests + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### baseUrl + +Type: `string` + +Use this to pass directly the address of your distant server address with the port running your application + +### browser + +Type: `string` + +The browser to run tests in. + +### ciBuildId + +Type: `string` + +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 + +### cypressConfig + +Type: `string` + +The path of the Cypress configuration json file. + +### 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. + +### headless + +Default: `false` + +Type: `boolean` + +Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode + +### 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. + +### 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** + +### 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/data-access-documents/src/data/11.4.0/react/api-express/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-express/generators/application.md new file mode 100644 index 0000000000..c801960e6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-express/generators/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/build.md new file mode 100644 index 0000000000..5d732f43d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/build.md @@ -0,0 +1,48 @@ +# build + +Build a Gatsby app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### color + +Default: `true` + +Type: `boolean` + +Enable colored terminal output. + +### graphqlTracing + +Type: `boolean` + +Trace every graphql resolver, may have performance implications. + +### openTracingConfigFile + +Type: `string` + +Tracer configuration file (OpenTracing compatible). + +### prefixPaths + +Type: `boolean` + +Build site with link paths prefixed (set pathPrefix in your config). + +### profile + +Type: `boolean` + +Build site with react profiling. + +### uglify + +Default: `true` + +Type: `boolean` + +Build site without uglifying JS bundles (true by default). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/server.md new file mode 100644 index 0000000000..c19723ab14 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/executors/server.md @@ -0,0 +1,44 @@ +# server + +Starts server for app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### https + +Default: `false` + +Type: `boolean` + +Serve using HTTPS. + +### open + +Type: `boolean` + +Open the site in your (default) browser for you. + +### port + +Default: `4200` + +Type: `number` + +Port to listen on. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/application.md new file mode 100644 index 0000000000..444d19ee1b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/application.md @@ -0,0 +1,89 @@ +# 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/gatsby:application ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g application ... --dry-run +``` + +## Options + +### directory + +Alias(es): d + +Type: `string` + +A directory where the project is placed + +### e2eTestRunner + +Default: `cypress` + +Type: `string` + +Possible values: `cypress`, `none` + +Adds the specified e2e test runner + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files + +### name + +Type: `string` + +### style + +Alias(es): s + +Default: `css` + +Type: `string` + +Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `none` + +The file extension to be used for style files. + +### tags + +Alias(es): t + +Type: `string` + +Add tags to the project (used for linting) + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Adds the specified unit test runner diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/component.md new file mode 100644 index 0000000000..505bd2d0d8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/component.md @@ -0,0 +1,107 @@ +# component + +Create a 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/gatsby: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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/page.md new file mode 100644 index 0000000000..9310106396 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-gatsby/generators/page.md @@ -0,0 +1,107 @@ +# page + +Create a page + +## 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/gatsby:page ... +``` + +Show what will be generated without writing to disk: + +```bash +nx g page ... --dry-run +``` + +### Examples + +Generate a page in the mylib library: + +```bash +nx g page my-page --project=mylib +``` + +Generate a class component in the mylib library: + +```bash +nx g page my-page --project=mylib --classComponent +``` + +## Options + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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`, `none` + +The file extension to be used for style files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-jest/executors/jest.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-jest/executors/jest.md new file mode 100644 index 0000000000..51fa9df10e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-jest/executors/jest.md @@ -0,0 +1,222 @@ +# jest + +Run Jest unit tests + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### bail + +Alias(es): b + +Type: `number | boolean ` + +Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) + +### 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/en/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/en/cli#coverage) + +### 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/en/cli#colors) + +### colors + +Type: `boolean` + +Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/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/en/cli.html#--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/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) + +### jestConfig + +Type: `string` + +The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) + +### 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/en/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/en/cli#maxworkers-num) + +### 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/en/cli#onlychanged) + +### outputFile + +Type: `string` + +Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) + +### passWithNoTests + +Type: `boolean` + +Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/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/en/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/en/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/en/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/en/cli#testlocationinresults) + +### testNamePattern + +Alias(es): t + +Type: `string` + +Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) + +### testPathPattern + +Type: `array` + +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) + +### testResultsProcessor + +Type: `string` + +Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) + +### 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/en/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/en/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/en/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/en/cli#watchall) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-linter/executors/eslint.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-linter/executors/eslint.md new file mode 100644 index 0000000000..bf02ceff28 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-linter/executors/eslint.md @@ -0,0 +1,102 @@ +# eslint + +Run ESLint on a project + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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). + +### ignorePath + +Type: `string` + +The path of the .eslintignore file. + +### lintFilePatterns + +Type: `array` + +One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. + +### 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/data-access-documents/src/data/11.4.0/react/api-linter/executors/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-linter/executors/lint.md new file mode 100644 index 0000000000..2ca75a0556 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-linter/executors/lint.md @@ -0,0 +1,110 @@ +# lint + +**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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). + +### linter + +Default: `eslint` + +Type: `string` + +Possible values: `eslint`, `tslint` + +The tool to use for running lint checks. + +### 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/data-access-documents/src/data/11.4.0/react/api-nest/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/application.md new file mode 100644 index 0000000000..cca4d44354 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/application.md @@ -0,0 +1,89 @@ +# application + +Create a nest 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 + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +The name of the application. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/react/api-nest/generators/class.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/class.md new file mode 100644 index 0000000000..6e68d6c09b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/class.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/controller.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/controller.md new file mode 100644 index 0000000000..675f120e09 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/controller.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/decorator.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/decorator.md new file mode 100644 index 0000000000..3d78970593 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/decorator.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/filter.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/filter.md new file mode 100644 index 0000000000..ae68bfb9c7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/filter.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/gateway.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/gateway.md new file mode 100644 index 0000000000..158e69e78e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/gateway.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/guard.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/guard.md new file mode 100644 index 0000000000..79030bc77d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/guard.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interceptor.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interceptor.md new file mode 100644 index 0000000000..baf34e7065 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interceptor.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interface.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interface.md new file mode 100644 index 0000000000..5d8e361733 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/interface.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/library.md new file mode 100644 index 0000000000..5e59e4f3c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/library.md @@ -0,0 +1,167 @@ +# library + +Create a new nest 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 + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### controller + +Default: `false` + +Type: `boolean` + +Include a controller with the library + +### directory + +Alias(es): d + +Type: `string` + +A directory where the app 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### publishable + +Type: `boolean` + +Create a publishable library. + +### service + +Default: `false` + +Type: `boolean` + +Include a service with the library. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/react/api-nest/generators/middleware.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/middleware.md new file mode 100644 index 0000000000..a98c69da25 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/middleware.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/module.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/module.md new file mode 100644 index 0000000000..d6c89ec362 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/module.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/pipe.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/pipe.md new file mode 100644 index 0000000000..3bc792d24f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/pipe.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/provider.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/provider.md new file mode 100644 index 0000000000..546a44396b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/provider.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/resolver.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/resolver.md new file mode 100644 index 0000000000..76cde3741d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/resolver.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/service.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/service.md new file mode 100644 index 0000000000..241519d348 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nest/generators/service.md @@ -0,0 +1,65 @@ +# 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 + +### directory + +Alias(es): d,path + +Type: `string` + +Directory where the generated files are placed + +### flat + +Default: `false` + +Type: `boolean` + +Flag to indicate if a directory is created. + +### name + +Type: `string` + +The name of generated generator + +### project + +Alias(es): p + +Type: `string` + +The nest project to target + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/build.md new file mode 100644 index 0000000000..c08477e5d0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/build.md @@ -0,0 +1,44 @@ +# build + +Build a Next.js app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### fileReplacements + +Type: `object[]` + +Replace files with other files in the build. + +#### replace + +Type: `string` + +undefined + +#### with + +Type: `string` + +undefined + +### nextConfig + +Type: `string` + +Path to a function which takes phase, config, and builder options, and returns the resulting config. + +### outputPath + +Type: `string` + +The output path of the generated files. + +### root + +Type: `string` + +The source root diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/export.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/export.md new file mode 100644 index 0000000000..278037938d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/export.md @@ -0,0 +1,28 @@ +# export + +Export a Next.js app. The exported application is located at dist/$outputPath/exported. + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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/data-access-documents/src/data/11.4.0/react/api-next/executors/server.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/server.md new file mode 100644 index 0000000000..e417e9e80c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/executors/server.md @@ -0,0 +1,64 @@ +# server + +Serve a Next.js app + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/react/api-next/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/application.md new file mode 100644 index 0000000000..7fe8a93eed --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/application.md @@ -0,0 +1,131 @@ +# 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. + +### 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) + +### 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. + +### 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/data-access-documents/src/data/11.4.0/react/api-next/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/component.md new file mode 100644 index 0000000000..bb6cffb91e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/component.md @@ -0,0 +1,107 @@ +# 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 + +### 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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/react/api-next/generators/page.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/page.md new file mode 100644 index 0000000000..82ca21954e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-next/generators/page.md @@ -0,0 +1,107 @@ +# 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 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 + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +The name of the component. + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/react/api-node/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/build.md new file mode 100644 index 0000000000..32a9e66ddf --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/build.md @@ -0,0 +1,162 @@ +# build + +Build a Node application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### 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. + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### 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. + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### 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 https: //webpack.github.io/analyse. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### verbose + +Default: `false` + +Type: `boolean` + +Emits verbose output + +### watch + +Default: `false` + +Type: `boolean` + +Run build when files change. + +### webpackConfig + +Type: `string` + +Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/execute.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/execute.md new file mode 100644 index 0000000000..39206f6073 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/execute.md @@ -0,0 +1,64 @@ +# execute + +Execute a Node application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### args + +Type: `array` + +Extra args when starting the app + +### buildTarget + +Type: `string` + +The target to run to build you 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: `0` + +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/data-access-documents/src/data/11.4.0/react/api-node/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/package.md new file mode 100644 index 0000000000..f132ef0604 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/executors/package.md @@ -0,0 +1,78 @@ +# package + +Package a Node library + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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` + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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 + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/react/api-node/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/generators/application.md new file mode 100644 index 0000000000..5ed7f18cd4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/generators/application.md @@ -0,0 +1,115 @@ +# 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipPackageJson + +Default: `false` + +Type: `boolean` + +Do not add dependencies to package.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/data-access-documents/src/data/11.4.0/react/api-node/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/generators/library.md new file mode 100644 index 0000000000..864624be6d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-node/generators/library.md @@ -0,0 +1,167 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.base.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/react/api-nx-plugin/executors/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/executors/e2e.md new file mode 100644 index 0000000000..17ff6fa9cd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/executors/e2e.md @@ -0,0 +1,26 @@ +# e2e + +Creates and runs an e2e for a Nx Plugin + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### jestConfig + +Type: `string` + +Jest config file + +### target + +Type: `string` + +the target Nx Plugin project and build + +### tsSpecConfig + +Type: `string` + +[Deprecated] Spec tsconfig file diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/executor.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/executor.md new file mode 100644 index 0000000000..aed9587869 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/executor.md @@ -0,0 +1,65 @@ +# 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 + +### description + +Alias(es): d + +Type: `string` + +Executor description + +### name + +Type: `string` + +Executor name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/generator.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/generator.md new file mode 100644 index 0000000000..64d2686a74 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/generator.md @@ -0,0 +1,65 @@ +# 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 + +### description + +Alias(es): d + +Type: `string` + +Generator description + +### name + +Type: `string` + +Generator name + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### unitTestRunner + +Default: `jest` + +Type: `string` + +Possible values: `jest`, `none` + +Test runner to use for unit tests diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/migration.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/migration.md new file mode 100644 index 0000000000..82867640a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/migration.md @@ -0,0 +1,73 @@ +# 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 + +### 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 + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### version + +Alias(es): v + +Type: `string` + +Version to use for the migration diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/plugin.md new file mode 100644 index 0000000000..f7bce6c1ba --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-nx-plugin/generators/plugin.md @@ -0,0 +1,97 @@ +# 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 + +### 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. + +### name + +Type: `string` + +Plugin name + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/react/api-react/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/application.md new file mode 100644 index 0000000000..8bb109275c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/application.md @@ -0,0 +1,173 @@ +# 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/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. + +### 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. + +### 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. + +### 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). + +### 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/data-access-documents/src/data/11.4.0/react/api-react/generators/component-cypress-spec.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component-cypress-spec.md new file mode 100644 index 0000000000..58b52f635a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component-cypress-spec.md @@ -0,0 +1,45 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root? + +### js + +Default: `false` + +Type: `boolean` + +Generate JavaScript files rather than TypeScript files. + +### project + +Type: `string` + +The project name for which to generate tests. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component-story.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component-story.md new file mode 100644 index 0000000000..35ef6ced9c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component-story.md @@ -0,0 +1,37 @@ +# 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 + +Type: `string` + +Relative path to the component file from the library root + +### project + +Type: `string` + +The project name where to add the components. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component.md new file mode 100644 index 0000000000..2633a1c1e9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/component.md @@ -0,0 +1,145 @@ +# component + +Create a 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 + +### 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. + +### 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. + +### name + +Type: `string` + +The name of the component. + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case component file name (e.g. App.tsx). + +### project + +Alias(es): p + +Type: `string` + +The name of the project. + +### 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/data-access-documents/src/data/11.4.0/react/api-react/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/library.md new file mode 100644 index 0000000000..fe6358933e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/library.md @@ -0,0 +1,181 @@ +# 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/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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the library route to. + +### buildable + +Default: `false` + +Type: `boolean` + +Generate a buildable library. + +### component + +Default: `true` + +Type: `boolean` + +Generate a default component. + +### 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. + +### name + +Type: `string` + +Library name + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files. + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### 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/data-access-documents/src/data/11.4.0/react/api-react/generators/redux.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/redux.md new file mode 100644 index 0000000000..cda1e636d6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/redux.md @@ -0,0 +1,67 @@ +# 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 + +### appProject + +Alias(es): a + +Type: `string` + +The application project to add the slice to. + +### directory + +Alias(es): d + +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. + +### name + +Type: `string` + +Redux slice name. + +### 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/data-access-documents/src/data/11.4.0/react/api-react/generators/stories.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/stories.md new file mode 100644 index 0000000000..8189aab8a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/stories.md @@ -0,0 +1,45 @@ +# 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 + +### 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. + +### project + +Type: `string` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-configuration.md new file mode 100644 index 0000000000..17f5719530 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-configuration.md @@ -0,0 +1,67 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator. + +### generateCypressSpecs + +Type: `boolean` + +Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator + +### generateStories + +Type: `boolean` + +Automatically generate \*.stories.ts files for components declared in this library. + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..6253cf44e8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-react/generators/storybook-migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/data-access-documents/src/data/11.4.0/react/api-storybook/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/executors/build.md new file mode 100644 index 0000000000..2255ef48e7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/executors/build.md @@ -0,0 +1,44 @@ +# build + +Build Storybook + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### 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. + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/executors/storybook.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/executors/storybook.md new file mode 100644 index 0000000000..1ddae5eccf --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/executors/storybook.md @@ -0,0 +1,88 @@ +# storybook + +Serve Storybook + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### docsMode + +Default: `false` + +Type: `boolean` + +Build a documentation-only site using addon-docs. + +### host + +Default: `localhost` + +Type: `string` + +Host to listen on. + +### 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. + +### 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. + +### staticDir + +Type: `array` + +Directory where to load static files from, array of strings + +### uiFramework (**hidden**) + +Default: `@storybook/angular` + +Type: `string` + +Storybook framework npm package + +### watch + +Default: `true` + +Type: `boolean` + +Watches for changes and rebuilds application diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/configuration.md new file mode 100644 index 0000000000..ecd1fe6262 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/configuration.md @@ -0,0 +1,63 @@ +# 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 + +### configureCypress + +Type: `boolean` + +Run the cypress-configure generator + +### 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` + +Library or application name + +### uiFramework + +Type: `string` + +Possible values: `@storybook/angular`, `@storybook/react` + +Storybook UI Framework to use diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/cypress-project.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/cypress-project.md new file mode 100644 index 0000000000..8b70e27fd3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/cypress-project.md @@ -0,0 +1,49 @@ +# 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 + +### 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` + +Library or application name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/migrate-defaults-5-to-6.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/migrate-defaults-5-to-6.md new file mode 100644 index 0000000000..4054001fcf --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-storybook/generators/migrate-defaults-5-to-6.md @@ -0,0 +1,47 @@ +# 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/data-access-documents/src/data/11.4.0/react/api-web/executors/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/build.md new file mode 100644 index 0000000000..488a28cc01 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/build.md @@ -0,0 +1,252 @@ +# build + +Build a application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### assets + +Type: `array` + +List of static application assets. + +### baseHref + +Default: `/` + +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. + +### 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` + +undefined + +#### with + +Type: `string` + +undefined + +### index + +Type: `string` + +HTML File which will be contain the application + +### main + +Type: `string` + +The name of the main entry-point file. + +### 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. + +### scripts + +Type: `array` + +External Scripts which will be included before the main application entry + +### showCircularDependencies + +Default: `true` + +Type: `boolean` + +Show circular dependency warnings on builds. + +### sourceMap + +Default: `true` + +Type: `boolean` + +Output sourcemaps. + +### statsJson + +Default: `false` + +Type: `boolean` + +Generates a 'stats.json' file which can be analyzed using tools such as: #webpack-bundle-analyzer' or https://webpack.github.io/analyse. + +### styles + +Type: `array` + +External Styles which will be included with the application + +### subresourceIntegrity + +Default: `false` + +Type: `boolean` + +Enables the use of subresource integrity validation. + +### tsConfig + +Type: `string` + +The name of the Typescript configuration file. + +### 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/data-access-documents/src/data/11.4.0/react/api-web/executors/dev-server.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/dev-server.md new file mode 100644 index 0000000000..188d8caf81 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/dev-server.md @@ -0,0 +1,106 @@ +# dev-server + +Serve a web application + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### allowedHosts + +Type: `string` + +This option allows you to whitelist services that are allowed to access the dev server. + +### baseHref + +Default: `/` + +Type: `string` + +Base url for the application being built. + +### buildTarget + +Type: `string` + +Target which builds the application + +### 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/data-access-documents/src/data/11.4.0/react/api-web/executors/file-server.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/file-server.md new file mode 100644 index 0000000000..10e401d924 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/file-server.md @@ -0,0 +1,78 @@ +# file-server + +Serve a web application from a folder + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### buildTarget + +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/data-access-documents/src/data/11.4.0/react/api-web/executors/package.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/package.md new file mode 100644 index 0000000000..8ac18a761a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/executors/package.md @@ -0,0 +1,122 @@ +# package + +Package a library + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### assets + +Type: `array` + +List of static assets. + +### babelConfig + +Type: `string` + +(deprecated) Path to a function which takes a babel config and returns an updated babel config + +### buildableProjectDepsInPackageJsonType + +Default: `peerDependencies` + +Type: `string` + +Possible values: `dependencies`, `peerDependencies` + +When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` + +### deleteOutputPath + +Default: `true` + +Type: `boolean` + +Delete the output path before building. + +### entryFile + +Type: `string` + +The path to the entry file, relative to project. + +### 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. + +### 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`). + +### outputPath + +Type: `string` + +The output path of the generated files. + +### project + +Type: `string` + +The path to package.json file. + +### rollupConfig + +Type: `string` + +Path to a function which takes a rollup config and returns an updated rollup config + +### tsConfig + +Type: `string` + +The path to tsconfig file. + +### 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/data-access-documents/src/data/11.4.0/react/api-web/generators/application.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/generators/application.md new file mode 100644 index 0000000000..914d89a1c5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-web/generators/application.md @@ -0,0 +1,103 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### 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/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-commands.md new file mode 100644 index 0000000000..f1d67f0b69 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-commands.md @@ -0,0 +1,220 @@ +# run-commands + +Run any custom commands with Nx + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Examples + +`workspace.json`: + +```json +//... +"frontend": { + "architect": { + //... + "ls-project-root": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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": { + "builder": "@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 command finished the moment the string appears in `stdout` or `stderr`: + +```json +"finish-when-ready": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "echo 'READY' && sleep 5 && echo 'FINISHED'", + "readyWhen": "READY" + } +} +``` + +```bash +nx run frontend:finish-when-ready +``` + +The above command 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 dependency 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": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/frontend/tsconfig.app.json" + } + } + } +}, +"api": { + "architect": { + //... + "generate-docs": { + "builder": "@nrwl/workspace:run-commands", + "options": { + "command": "npx compodoc -p apps/api/tsconfig.app.json" + } + } + } +} +``` + +## Properties + +### 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` + +### cwd + +Type: `string` + +Current working directory of the commands. + +### 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. 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/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-script.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-script.md new file mode 100644 index 0000000000..de42c421fd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/executors/run-script.md @@ -0,0 +1,14 @@ +# run-script + +Run an npm script using Nx + +Properties can be configured in workspace.json when defining the executor, or when invoking it. +Read more about how to use executors and the CLI here: https://nx.dev/react/getting-started/cli-overview#running-tasks. + +## Properties + +### script + +Type: `string` + +Script to run in child process diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/library.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/library.md new file mode 100644 index 0000000000..1f0f79e2a7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/library.md @@ -0,0 +1,141 @@ +# 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 + +### babelJest + +Default: `false` + +Type: `boolean` + +Use babel instead ts-jest + +### 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`, `tslint` + +The tool to use for running lint checks. + +### name + +Type: `string` + +Library name + +### pascalCaseFiles + +Alias(es): P + +Default: `false` + +Type: `boolean` + +Use pascal case file names. + +### skipFormat + +Default: `false` + +Type: `boolean` + +Skip formatting files + +### skipTsConfig + +Default: `false` + +Type: `boolean` + +Do not update tsconfig.json for development experience. + +### strict + +Default: `false` + +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/data-access-documents/src/data/11.4.0/react/api-workspace/generators/move.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/move.md new file mode 100644 index 0000000000..723a022898 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/move.md @@ -0,0 +1,75 @@ +# 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 + +Type: `string` + +The folder to move the project into + +### importPath + +Type: `string` + +The new import path to use in the tsconfig.base.json + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to move + +### 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/data-access-documents/src/data/11.4.0/react/api-workspace/generators/remove.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/remove.md new file mode 100644 index 0000000000..a83d277938 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/remove.md @@ -0,0 +1,71 @@ +# 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 + +### forceRemove + +Alias(es): force-remove + +Default: `false` + +Type: `boolean` + +When true, forces removal even if the project is still in use. + +### projectName + +Alias(es): project + +Type: `string` + +The name of the project to remove + +### skipFormat + +Alias(es): skip-format + +Default: `false` + +Type: `boolean` + +Skip formatting files. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/run-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/run-commands.md new file mode 100644 index 0000000000..fb24979f18 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/run-commands.md @@ -0,0 +1,73 @@ +# 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 + +Type: `string` + +Command to run + +### cwd + +Type: `string` + +Current working directory of the command + +### envFile + +Type: `string` + +Env files to be loaded before executing the commands + +### name + +Type: `string` + +Target name + +### 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. + +### project + +Type: `string` + +Project name diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/workspace-generator.md new file mode 100644 index 0000000000..7d95e3eef7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/api-workspace/generators/workspace-generator.md @@ -0,0 +1,43 @@ +# 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/data-access-documents/src/data/11.4.0/react/cli/affected-apps.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-apps.md new file mode 100644 index 0000000000..a3a0b085a3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-apps.md @@ -0,0 +1,99 @@ +# affected:apps + +Print applications affected by changes + +## Usage + +```bash +nx affected:apps +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:apps --base=master --head=HEAD +``` + +Print the names of all the apps affected by the last commit on master: + +```bash +nx affected:apps --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/react/cli/affected-build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-build.md new file mode 100644 index 0000000000..87dbc13855 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-build.md @@ -0,0 +1,133 @@ +# affected:build + +Build applications and publishable libraries affected by changes + +## Usage + +```bash +nx affected:build +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run build in parallel: + +```bash +nx affected:build --parallel --maxParallel=5 +``` + +Rerun the build target only for the projects that failed last time: + +```bash +nx affected:build --only-failed +``` + +Run the build target for all projects: + +```bash +nx affected:build --all +``` + +Run the build target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected:build --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:build --base=master --head=HEAD +``` + +Run build for all the projects affected by the last commit on master: + +```bash +nx affected:build --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected:build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/react/cli/affected-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-dep-graph.md new file mode 100644 index 0000000000..1f5311aa42 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-dep-graph.md @@ -0,0 +1,133 @@ +# affected:dep-graph + +Graph dependencies affected by changes + +## Usage + +```bash +nx affected:dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: + +```bash +nx affected:dep-graph --files=libs/mylib/src/index.ts +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +Save the dep graph of the workspace in a json file, and highlight the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.json +``` + +Generate a static website with dep graph data in an html file, highlighting the projects affected by the changes between master and HEAD (e.g., PR): + +```bash +nx affected:dep-graph --base=master --head=HEAD --file=output.html +``` + +Open the dep graph of the workspace in the browser, and highlight the projects affected by the last commit on master: + +```bash +nx affected:dep-graph --base=master~1 --head=master +``` + +Open the dep graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: + +```bash +nx affected:dep-graph --exclude=project-one,project-two +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### head + +Latest commit of the current branch (usually HEAD) + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### port + +Bind the dep 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 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-e2e.md new file mode 100644 index 0000000000..13992dcca8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-e2e.md @@ -0,0 +1,121 @@ +# affected:e2e + +Run e2e tests for the applications affected by changes + +## Usage + +```bash +nx affected:e2e +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:e2e --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:e2e --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:e2e --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:e2e --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/react/cli/affected-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-libs.md new file mode 100644 index 0000000000..f9648615be --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-libs.md @@ -0,0 +1,99 @@ +# affected:libs + +Print libraries affected by changes + +## Usage + +```bash +nx affected:libs +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 master and HEAD (e.g., PR): + +```bash +nx affected:libs --base=master --head=HEAD +``` + +Print the names of all the libs affected by the last commit on master: + +```bash +nx affected:libs --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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` + +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/data-access-documents/src/data/11.4.0/react/cli/affected-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-lint.md new file mode 100644 index 0000000000..93c30beaa9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-lint.md @@ -0,0 +1,121 @@ +# affected:lint + +Lint projects affected by changes + +## Usage + +```bash +nx affected:lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run lint in parallel: + +```bash +nx affected:lint --parallel --maxParallel=5 +``` + +Rerun the lint target only for the projects that failed last time: + +```bash +nx affected:lint --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:lint --base=master --head=HEAD +``` + +Run lint for all the projects affected by the last commit on master: + +```bash +nx affected:lint --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/react/cli/affected-test.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-test.md new file mode 100644 index 0000000000..7339dc151c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected-test.md @@ -0,0 +1,121 @@ +# affected:test + +Test projects affected by changes + +## Usage + +```bash +nx affected:test +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Run tests in parallel: + +```bash +nx affected:test --parallel --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected:test --only-failed +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected:test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected:test --base=master~1 --head=master +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/react/cli/affected.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected.md new file mode 100644 index 0000000000..5b4b792fad --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/affected.md @@ -0,0 +1,143 @@ +# affected + +Run task for affected projects + +## Usage + +```bash +nx affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=5 +``` + +Rerun the test target only for the projects that failed last time: + +```bash +nx affected --target=test --only-failed +``` + +Run the test target for all projects: + +```bash +nx affected --target=test --all +``` + +Run the test target for the affected projects and also all the projects the affected projects depend on.: + +```bash +nx affected --target=test --with-deps +``` + +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 master and HEAD (e.g., PR): + +```bash +nx affected --target=test --base=master --head=HEAD +``` + +Run tests for all the projects affected by the last commit on master: + +```bash +nx affected --target=test --base=master~1 --head=master +``` + +Run build for all the projects affected by the last commit on master and their dependencies: + +```bash +nx affected --target=build --base=master~1 --head=master --with-deps +``` + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Isolate projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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/data-access-documents/src/data/11.4.0/react/cli/build.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/11.4.0/react/cli/dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/dep-graph.md new file mode 100644 index 0000000000..7de42387d7 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/dep-graph.md @@ -0,0 +1,89 @@ +# dep-graph + +Graph dependencies within workspace + +## Usage + +```bash +nx dep-graph +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Open the dep graph of the workspace in the browser: + +```bash +nx dep-graph +``` + +Save the dep graph into a json file: + +```bash +nx dep-graph --file=output.json +``` + +Generate a static website with dep graph into an html file, accompanied by an asset folder called static: + +```bash +nx dep-graph --file=output.html +``` + +Show the graph where every node is either an ancestor or a descendant of todos-feature-main: + +```bash +nx dep-graph --focus=todos-feature-main +``` + +Include project-one and project-two in the dep graph: + +```bash +nx dep-graph --include=project-one,project-two +``` + +Exclude project-one and project-two from the dep graph: + +```bash +nx dep-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 dep-graph --focus=todos-feature-main --exclude=project-one,project-two +``` + +## Options + +### exclude + +List of projects delimited by commas to exclude from the dependency graph. + +### file + +output file (e.g. --file=output.json or --file=dep-graph.html) + +### focus + +Use to show the dependency graph for a particular project and every node that is either an ancestor or a descendant. + +### groupByFolder + +Group projects by folder in dependency graph + +### help + +Show help + +### host + +Bind the dep graph server to a specific ip address. + +### port + +Bind the dep graph server to a specific port. + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/cli/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/e2e.md new file mode 100644 index 0000000000..279449cf40 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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/data-access-documents/src/data/11.4.0/react/cli/format-check.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/format-check.md new file mode 100644 index 0000000000..8582f2a9a5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/format-check.md @@ -0,0 +1,81 @@ +# format:check + +Check for un-formatted files + +## Usage + +```bash +nx format:check +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/react/cli/format-write.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/format-write.md new file mode 100644 index 0000000000..356fdf198a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/format-write.md @@ -0,0 +1,81 @@ +# format:write + +Overwrite un-formatted files + +## Usage + +```bash +nx format:write +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### all + +All projects + +### base + +Base of the current branch (usually master) + +### 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 + +### only-failed + +Default: `false` + +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/data-access-documents/src/data/11.4.0/react/cli/generate.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/generate.md new file mode 100644 index 0000000000..0fa39dc3f6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/generate.md @@ -0,0 +1,93 @@ +# 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 the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/react/cli/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/11.4.0/react/cli/list.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/list.md new file mode 100644 index 0000000000..312250e849 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/list.md @@ -0,0 +1,41 @@ +# list + +Lists installed plugins, capabilities of installed plugins and other available plugins. + +## Usage + +```bash +nx list +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 + +Default: `null` + +The name of an installed plugin to query + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/cli/migrate.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/migrate.md new file mode 100644 index 0000000000..2fcd071917 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/migrate.md @@ -0,0 +1,60 @@ + # 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 to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/react/cli/print-affected.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/print-affected.md new file mode 100644 index 0000000000..1ac11d2fd8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/print-affected.md @@ -0,0 +1,115 @@ +# print-affected + +Graph execution plan + +## Usage + +```bash +nx print-affected +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +### Examples + +Print information about affected projects and the dependency graph.: + +```bash +nx print-affected +``` + +Print information about the projects affected by the changes between master and HEAD (e.g,. PR).: + +```bash +nx print-affected --base=master --head=HEAD +``` + +Prints information about the affected projects and a list of tasks to test them.: + +```bash +nx print-affected --target=test +``` + +Prints information about the affected projects and a list of tasks to build them and their dependencies.: + +```bash +nx print-affected --target=build --with-deps +``` + +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 master) + +### 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` + +Isolate projects which previously failed + +### runner + +This is the name of the tasks runner configured in nx.json + +### select + +### 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/data-access-documents/src/data/11.4.0/react/cli/report.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/report.md new file mode 100644 index 0000000000..0d7c3480d5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/report.md @@ -0,0 +1,21 @@ +# report + +Reports useful version numbers to copy into the Nx issue template + +## Usage + +```bash +nx report +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run-many.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run-many.md new file mode 100644 index 0000000000..0a247289e0 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run-many.md @@ -0,0 +1,97 @@ +# run-many + +Run task for multiple projects + +## Usage + +```bash +nx run-many +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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 --maxParallel=2 +``` + +Build proj1 and proj2 and all their dependencies.: + +```bash +nx run-many --target=test --projects=proj1,proj2 --with-deps +``` + +## Options + +### all + +Run the target on all projects in the workspace + +### configuration + +This is the configuration to use when performing tasks on projects + +### help + +Show help + +### maxParallel + +Max number of parallel processes. This flag is ignored if the parallel option is set to `false`. (default: 3) + +### only-failed + +Default: `false` + +Only run the target on projects which previously failed + +### parallel + +Parallelize the command (default: false) + +### 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` + +Include dependencies of specified projects when computing what to run diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/react/cli/serve.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/11.4.0/react/cli/test.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/11.4.0/react/cli/workspace-generator.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/workspace-generator.md new file mode 100644 index 0000000000..dca864f7aa --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/workspace-generator.md @@ -0,0 +1,29 @@ +# workspace-generator + +Runs a workspace generator from the tools/generators directory + +## Usage + +```bash +nx workspace-generator +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/react/cli/workspace-lint.md b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/workspace-lint.md new file mode 100644 index 0000000000..d3eeca5b2b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/cli/workspace-lint.md @@ -0,0 +1,21 @@ +# workspace-lint + +Lint workspace or list of files. Note: To exclude files from this lint rule, you can add them to the ".nxignore" file + +## Usage + +```bash +nx workspace-lint +``` + +Install `nx` globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn nx`. + +## Options + +### help + +Show help + +### version + +Show version number diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/examples/apollo-react.md b/nx-dev/data-access-documents/src/data/11.4.0/react/examples/apollo-react.md new file mode 100644 index 0000000000..e3aa0cbe28 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/examples/apollo-react.md @@ -0,0 +1,12 @@ +# 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/data-access-documents/src/data/11.4.0/react/examples/react-nx.md b/nx-dev/data-access-documents/src/data/11.4.0/react/examples/react-nx.md new file mode 100644 index 0000000000..69add2be32 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/examples/react-nx.md @@ -0,0 +1,12 @@ +# 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/data-access-documents/src/data/11.4.0/react/executors.json b/nx-dev/data-access-documents/src/data/11.4.0/react/executors.json new file mode 100644 index 0000000000..ded073647f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/executors.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "linter", + "nest", + "next", + "node", + "nx-plugin", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/generators.json b/nx-dev/data-access-documents/src/data/11.4.0/react/generators.json new file mode 100644 index 0000000000..46a738dc38 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/generators.json @@ -0,0 +1,15 @@ +[ + "angular", + "cypress", + "express", + "gatsby", + "jest", + "nest", + "next", + "node", + "nx-plugin", + "react", + "storybook", + "web", + "workspace" +] diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/EGH_ScalingReactNx.png b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/EGH_ScalingReactNx.png new file mode 100644 index 0000000000..308795a5a6 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/EGH_ScalingReactNx.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/advanced-nx-workspace-course.png b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/advanced-nx-workspace-course.png new file mode 100644 index 0000000000..bf8a9f31fe Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/advanced-nx-workspace-course.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/getting-started.md b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/getting-started.md new file mode 100644 index 0000000000..5d94dc04f4 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/getting-started.md @@ -0,0 +1,28 @@ +# Getting Started + +Nx is a suite of powerful, extensible dev tools that help you develop, test, build, and scale with React and React frameworks like Gatsby, Next.js, React Native, etc. + +## 10-Minute Nx Overview + + + +## Create Nx Workspace + +Creating an Nx workspace is easy. Run the following command to set up an Nx workspace with a React app in it. + +```bash +npx create-nx-workspace --preset=react +``` + +## Learn Nx Fundamentals + +- [Interactive Nx Tutorial (with videos)](/{{framework}}/tutorial/01-create-application) +- [Free Nx Course on Egghead: Scale React Development with Nx](https://egghead.io/playlists/scale-react-development-with-nx-4038) +- [45-Minute Walkthrough](https://www.youtube.com/watch?v=jCf92IyR-GE) + +## Dive Deep + +- [Nx CLI](/{{framework}}/getting-started/cli-overview) +- [Configuration Files](/{{framework}}/getting-started/configuration) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/resources.md b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/resources.md new file mode 100644 index 0000000000..26a48e64ff --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/getting-started/resources.md @@ -0,0 +1,74 @@ +# Resources + +## Quick Introductions (10 minutes) + + + +## Egghead: Scale React Development with Nx (free) + +[![Egghead course: Scale React Development with Nx](./EGH_ScalingReactNx.png)](https://egghead.io/playlists/scale-react-development-with-nx-4038) + +## Nx Workspace (free) + + + +## Advanced Nx Workspace (premium) + +[![Advanced Nx Workspace](./advanced-nx-workspace-course.png)](https://nxplaybook.com/p/advanced-nx-workspaces) + +## 45-Minute Walkthrough + + + +## Resources + +### Highlights + +- [Nrwl Talks, Presentations, and Podcasts playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dHHWx4JIORwfnEajRv6FG5m) + +- [Nx Blog Posts](https://blog.nrwl.io/nx/home) + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. + +- [Nx Office Hours playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dE8KLQ5zd3fQwu_yQHjTmR5) + +### Nx Demo & Tutorial Videos + +- [React Development At Scale (React Vancouver Virtual Meetup)](https://youtu.be/ZGXuzVipe1U?t=3721), Jack Hsu (May 27, 2020) + +- [Scalable React Development (React Summit Remote Edition)](https://www.youtube.com/watch?v=Lr-u2ALSEQg), Jason Jean (April 17, 2020) + Slides: [https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/](https://prezi.com/view/fm9sUbR7vbr5fZlO9C8D/) + +- [Develop like Google, Microsoft, and Facebook with Nx - Dev Nexus](https://prezi.com/view/BVhl92reqg7cnhvv6hhH/), Jason Jean (February 18, 2020) + +- [React Roundup: Nx and Monorepos](https://player.fm/series/react-round-up/rru-081-nx-and-monorepos-with-jeffrey-cross-and-victor-savkin), Victor Savkin (Oct 1, 2019) + +- [Nx Dev Tools for Monorepos, In-Depth Explainer (React)](https://www.youtube.com/watch?v=jCf92IyR-GE) + +- [High Quality React apps with Nx & Cypress](https://youtu.be/mfJBLhjYMdo) + +- [Storybook Integration with Nx](https://youtu.be/sFpqyjT7u4s) + +- [Building Custom Plugins for Nx](https://youtu.be/XYO689PAhow) + +- [Improved Dependency Graph Visualization for Nx](https://youtu.be/cMZ-ReC-jWU) + +- [Group all your stories into a single viewable Storybook with Nx](https://youtu.be/c323HOuFKkA) + +- [Debug Nx with Node and VSCode](https://youtu.be/OGV4R0cPRPc) + +- [Debug your Jest tests in Nx with VSCode](https://youtu.be/9_lgM2nokLg) + +- [Introducing Nx Cloud](https://youtu.be/pwG20nNTEQc) + +- [Setting up distributed caching using Nx Cloud, @nrwl/nx-cloud](https://youtu.be/w1-GiB74ddc) + +### Books amd Blogs + +- [High Quality React apps with Nx & Cypress](https://cypress.io/blog/2020/04/14/high-quality-react-apps-with-nx-cypress/) (April 2020) + +- [Shell Library patterns with Nx and Monorepo Architectures](https://indepth.dev/the-shell-library-patterns-with-nx-and-monorepo-architectures/) (March 2020) + +### Misc + +- [nx-examples](https://github.com/nrwl/nx-examples) repo has branches for different nx comments to display expected behavior and example app and libraries. Check out the branch (workspace, ngrx...) to see what gets created for you. More info on readme. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/guides/adding-assets.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/adding-assets.md new file mode 100644 index 0000000000..a4e9ffb837 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/adding-assets.md @@ -0,0 +1,39 @@ +# Adding Images, Fonts, and Files + +With Nx, you can **`import` assets directly from your TypeScript/JavaScript code**. + +```typescript jsx +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 jsx +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. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/guides/cli-overview.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/cli-overview.md new file mode 100644 index 0000000000..5030c09120 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/cli-overview.md @@ -0,0 +1,265 @@ +# Nx CLI + +The Nx CLI is a command-line interface tool that helps you setup, develop, build, and maintain applications. It provides commands for: + +- Generating new applications, and libraries with recommended defaults. +- Running a development webserver that rebuilds your app on changes. +- Generating a dependency graph for your application. +- Building, and running unit and E2E test for apps, and libraries affected by your changes. +- Formatting your source code to modern standards. +- ... + +## Installing the CLI + +Install the Nx CLI globally on your system using your preferred package manager: + +Using npm: + +```bash +npm install -g nx +``` + +Using yarn: + +```bash +yarn global add nx +``` + +After that, you will have an `nx` executable you can use to run commands in your workspace. + +If you don't have the Nx CLI installed globally, you can invoke `nx` using `yarn nx` and `npm run nx`. + +## Help and List + +`nx help` will print a short description of every command. You can also pass `--help` to a command to see the available options (e.g., `nx affected --help`). + +[`nx list`](/{{framework}}/cli/list) will print the list of installed plugins and the list of plugins you can install. You can also pass a plugin name to it (e.g., `nx list @nrwl/react`) to learn more about what the capabilities of that plugin. + +## Generating Code + +The Nx CLI has an advanced code generator. With it, you can generate new applications, libraries, components, state management utilities. You can change existing applications. And, because the Nx CLI comes with an implementation of a virtual file system, you can preview the changes without affecting anything on disk. + +The code generation recipes are called generators. Generators provide the underlying APIs for scaffolding, and utilities to automate changes to your filesystem. The example below is the command to generate a new application. + +```sh +nx generate @nrwl/react:application myapp +``` + +The `@nrwl/react` package contains a collection of generators, with `application` being the one used in this example. The Nx CLI applies the generator to your workspace, verifying that the provided options are valid, and the destination files don't already exist. Once the validations are passed, the new files are generated, or existing files are updated. You can also customize the output of the generated application, by passing options to the generator. + +```sh +nx generate @nrwl/react:application myapp --style=scss +``` + +You can preview the changes a generator makes by using the `--dry-run` option. It will output the potential files created, and/or updated during the execution of the generator. + +**Generate command:** + +`nx generate` runs generators to create or modify code given some inputs from the developer. + +- [nx generate](/{{framework}}/cli/generate) + Syntax: `nx generate [plugin]:[generator-name] [options]` + Example: `nx generate @nrwl/react:component mycmp --project=myapp` + +## Running Tasks + +The Nx CLI uses executors to perform tasks, such as building and bundling your application, running unit tests, or running E2E tests against a specific target, whether that be an application or workspace. + +You can configure the executors in `workspace.json`. + +```json +{ + "projects": { + "todos": { + "root": "apps/todos/", + "sourceRoot": "apps/todos/src", + "projectType": "application", + "targets": { + "serve": { + "executor": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + }, + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/todos/jest.config.js", + "tsConfig": "apps/todos/tsconfig.spec.json", + "setupFile": "apps/todos/src/test-setup.ts" + } + } + } + } + } +} +``` + +In the example above, the `todos` application has two targets: `serve` and `test`. The `serve` target uses the `@nrwl/web:dev-server` executor, and the `test` target uses `@nrwl/jest:jest`. Every target uses an executor which actually runs this target. So targets are analogous to typed npm scripts, and executors are analogous to typed shell scripts. + +You can run the target as follows: + +```bash +nx run todos:serve +nx run todos:test +``` + +A target can have multiple configuration. In the example above the serve target has two configurations: default and production. + +```bash +nx run todos:serve # default configuration +nx run todos:serve:production # production configuration +``` + +Because running target is such a common operation, you can also use the following syntax to do it: + +```bash +nx serve todos +nx serve todos --configuration=production +nx serve todos --prod +``` + +You can name your targets any way you want, define as many of them as you want, and use any executors you want to implement them. + +**These are some common targets:** + +- [nx build](/{{framework}}/cli/build) + Syntax: `nx build [project]` + Long form: `nx run [project]:build` + Example: `nx build my-app` +- [nx lint](/{{framework}}/cli/lint) + Syntax: `nx lint [project]` + Long form: `nx run [project]:lint` + Example: `nx lint my-app` +- [nx serve](/{{framework}}/cli/serve) + Syntax: `nx serve [project]` + Long form: `nx run [project]:serve` + Example: `nx serve my-app` +- [nx e2e](/{{framework}}/cli/e2e) + Syntax: `nx e2e [project]` + Long form: `nx run [project]:e2e` + Example: `nx e2e my-app` +- [nx test](/{{framework}}/cli/test) + Syntax: `nx test [project]` + Long form: `nx run [project]:test` + Example: `nx test my-app` + +## Running Tasks for Multiple Projects + +Nx allows you to run tasks across multiple projects. + +### Run-Many + +Run the same target for all projects. + +```sh +nx run-many --target=build --all +``` + +Run the same target for all projects in parallel. + +```sh +nx run-many --target=build --all --parallel --maxParallel=8 +``` + +Run the same target for selected projects. + +```sh +nx run-many --target=build --projects=app1,app2 +``` + +Run the same target for selected projects and their deps. + +```sh +nx run-many --target=build --projects=app1,app2 --with-deps +``` + +Run the same target for the projects that failed last time. + +```sh +nx run-many --target=build --all --only-failed +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the executor. + +```sh +nx run-many --target=build --all --prod +``` + +### Affected + +Run the same target for all the projects by the current code change (e.g., current Git branch). + +```sh +nx affected --target=build +``` + +Same but in parallel. + +```sh +nx affected --target=build --parallel --maxParallel=8 +``` + +By default, the current code change is defined as a diff between master and HEAD. You can change it as follows: + +```sh +nx affected --target=build --parallel --maxParallel=8 --base=origin/development --head=$CI_BRANCH_NAME +``` + +Running `affected` commands is very common, so Nx comes with a few shortcuts. + +```sh +nx affected:build +nx affected:test +nx affected:lint +nx affected:e2e +``` + +Any flags you pass to `run-many` that aren't Nx specific will be passed down to the executor. + +```sh +nx affected --target=build --prod +``` + +## Other Commands + +`nx print-affected` prints information about affected projects in the workspace. + +- [nx print-affected](/{{framework}}/cli/print-affected) + Syntax: `nx print-affected` + +`nx dep-graph` launches a visual graph of the dependencies between your projects. + +- [nx dep-graph](/{{framework}}/cli/dep-graph) + Syntax: `nx dep-graph` + +`nx affected:dep-graph` launches the dependency graph with all affected projects highlighted. + +- [nx affected:dep-graph](/{{framework}}/cli/affected-dep-graph) + Syntax: `nx affected:dep-graph` + +`nx list` lists all installed and available plugins. + +- [nx list](/{{framework}}/cli/list) + Syntax: `nx list` + +`nx report` prints basic information about the plugins used + +- [nx report](/{{framework}}/cli/report) + Syntax: `nx report` + +`nx format:write` formats your code + +- [nx format:write](/{{framework}}/cli/format-write) + Syntax: `nx format:write` + +`nx format:check` checks that your code is formatted + +- [nx format:check](/{{framework}}/cli/format-check) + Syntax: `nx format:check` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/guides/configuration.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/configuration.md new file mode 100644 index 0000000000..6eccc8816f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/configuration.md @@ -0,0 +1,361 @@ +# Configuration + +There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. + +## workspace.json + +The `workspace.json` configuration file contains information about the targets and generators. Let's look at the following example: + +```json +{ + "version": 2, + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "targets": { + "build": { + "executor": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + }, + "serve": { + "executor": "@nrwl/web:dev-server", + "options": { + "buildTarget": "myapp:build", + "proxyConfig": "apps/myapp/proxy.conf.json" + } + }, + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "apps/myapp/jest.config.js", + "tsConfig": "apps/myapp/tsconfig.spec.json" + } + } + } + }, + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "targets": { + "test": { + "executor": "@nrwl/jest:jest", + "options": { + "jestConfig": "libs/mylib/jest.config.js", + "tsConfig": "libs/mylib/tsconfig.spec.json" + } + } + } + } + }, + "cli": { + "defaultCollection": "@nrwl/react" + }, + "generators": { + "@nrwl/react:library": { + "js": true + } + } +} +``` + +### Projects + +The `projects` property configures all apps and libs. + +For instance, the following configures `mylib`. + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "targets": {} + } +} +``` + +- `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'. +- `targets` configures all the targets which define what tasks you can run against the library. + +### Targets + +Let's look at the simple target: + +```json +{ + "test": { + "executor": "@nrwl/jest:jest", + "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 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" +} +``` + +**Outputs** + +The `outputs` property lists the folders the executor will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. + +```json +{ + "build": { + "executor": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + } + } +} +``` + +**Configurations** + +The `configurations` property provides extra sets of values that will be merged into the options map. + +```json +{ + "build": { + "executor": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.ts" + }, + "configurations": { + "production": { + "optimization": true + } + } + } +} +``` + +You can select a configuration like this: `nx build myapp --configuration=production` or `nx run myapp:build:configuration=production`. + +The following show how the executor options get constructed: + +```bash +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. + +### Generators + +You can configure default generator options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. + +```json +{ + "generators": { + "@nrwl/react:library": { + "js": true + } + } +} +``` + +You can also do it on the project level: + +```json +{ + "mylib": { + "root": "libs/mylib/", + "sourceRoot": "libs/mylib/src", + "projectType": "library", + "generators": { + "@nrwl/react:component": { + "classComponent": true + } + }, + "targets": {} + } +} +``` + +### CLI Options + +The following command will generate a new library: `nx g @nrwl/react:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. + +```json +{ + "cli": { + "defaultCollection": "@nrwl/react" + } +} +``` + +### Version + +When the `version` of `workspace.json` is set to 2, `targets`, `generators` and `executor` properties are used instead of the version 1 properties `architect`, `schematics` and `builder`. + +## nx.json + +The `nx.json` file contains extra configuration options mostly related to the project graph. + +```json +{ + "npmScope": "happyorg", + "affected": { + "defaultBase": "master" + }, + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"] + } + } + }, + "implicitDependencies": { + "workspace.json": "*", + "package.json": { + "dependencies": "*", + "devDependencies": "*" + }, + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "myapp": { + "tags": [] + }, + "mylib": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` + +**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 `master`. + +### Tasks Runner Options + +Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. + +> A task is an invocation of a target. + +Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. + +- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. +- `strictlyOrderedTargets` defines the list of targets that need to be executed in the order defined by the dependency graph. Defaults to `['build']` +- `parallel` defines whether to run targets in parallel +- `maxParallel` defines the max number of processes used. +- `captureStderr` defines whether the cache will capture 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 will normalize the key length, so any length of key is acceptable. +- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. + +`runtimeCacheInputs` can be set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "@nrwl/workspace/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +You can configure `parallel` and `maxParallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel`. + +### 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 dependencies between shared files and projects 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` will affect every project. +- Changing the `dependencies` property in `package.json` will affect every project. +- Changing the `devDependencies` property in `package.json` will only affect `mylib`. +- Changing any of the custom check `scripts` in `package.json` will affect every project. +- Changing `globalFile` will only affect `myapp`. +- Changing any CSS file inside the `styles` directory will only affect `myapp`. + +You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. + +```json +{ + "projects": { + "myapp": { + "tags": [] + }, + "myapp-e2e": { + "tags": [], + "implicitDependencies": ["myapp"] + } + } +} +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/guides/environment-variables.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/environment-variables.md new file mode 100644 index 0000000000..f8f4460513 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/environment-variables.md @@ -0,0 +1,66 @@ +# 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 and NX prefixed env vars such as: `NODE_ENV` or `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` +3. `workspaceRoot/.local.env` +4. `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 `.local.env` files for their local environment and override any project defaults set in `.env` + +For example: + +1. `workspaceRoot/apps/my-app/.local.env` 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/.local.env` 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](/{{framework}}/core-concepts/computation-caching#nx-cloud-and-distributed-computation-memoization)). + +### 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](/{{framework}}/workspace/run-commands-executor#envfile) builder and execute your command inside of the builder diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/guides/js-and-ts.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/js-and-ts.md new file mode 100644 index 0000000000..f0c6f9e601 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/js-and-ts.md @@ -0,0 +1,14 @@ +# 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.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/data-access-documents/src/data/11.4.0/react/guides/nextjs.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/nextjs.md new file mode 100644 index 0000000000..f6f7391259 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/nextjs.md @@ -0,0 +1,228 @@ +# Next.js + +Nx comes with first-class Next.js support. In this guide we will look at how to use it. + +## Creating a New Nx Workspace + +Create a new Nx workspace. The easiest way to do it is to use npx. + +```bash +npx --ignore-existing create-nx-workspace happynrwl +``` + +You can also create a workspace with a Next.js application in place by running: + +```bash +npx --ignore-existing create-nx-workspace happynrwl --preset=next +``` + +## Adding Next.js capabilities to a workspace + +If you used the Next.js preset, you are all set and can skip this. If you created an empty workspace or have an existing workspace, you can add Next.js capabilities to the workspace: + +```bash +yarn add --dev @nrwl/next +``` + +## Generating a Next.js Application + +Run + +```bash +nx g @nrwl/next:app tuskdesk +``` + +and you will see the following: + +```treeview +happynrwl/ +├── apps/ +│   ├── tuskdesk/ +│   │   ├── pages/ +│   │   │   ├── index.css +│   │   │   └── index.tsx +│   │   ├── jest.conf.js +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── .eslintrc.json +│   └── tuskdesk-e2e/ +│   │   ├── src/ +│   │   │   ├── integrations/ +│   │   │   │   └── app.spec.ts +│   │   │   ├── fixtures/ +│   │   │   ├── plugins/ +│   │   │   └── support/ +│   │   ├── cypress.json +│   │   ├── tsconfig.e2e.json +│   │   └── .eslintrc.json +├── libs/ +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── .eslintrc.json +``` + +Run: + +- `nx serve tuskdesk` to serve the application +- `nx serve tuskdesk --prod` to serve the application in the production mode +- `nx build tuskdesk` to build the application +- `nx lint tuskdesk` to lint the application +- `nx test tuskdesk` to test the application using Jest +- `nx export tuskdesk` to export the application +- `nx e2e tuskdesk-e2e` to test the application using Cypress + +When using Next.js in Nx, you get the out-of-the-box support for TypeScript, Cypress, Jest. No need to configure anything: watch mode, source maps, and typings just work. + +## Generating a React Library + +Run + +```bash +nx g @nrwl/react:lib shared-components +``` + +and you will see the following: + +```treeview +happynrwl/ +├── apps/ +│   ├── tuskdesk/ +│   └── tuskdesk-e2e/ +├── libs/ +│   └── shared-components/ +│   ├── src/ +│   │ ├── lib/ +│   │ │ ├── home.css +│   │ │ ├── home.tsx +│   │ │ └── home.spec.tsx +│   │ └ index.ts +│   ├── jest.config.js +│   ├── tsconfig.json +│   ├── tsconfig.lib.json +│   ├── tsconfig.spec.json +│   └── tslint.json +├── nx.json +├── workspace.json +├── package.json +├── tools/ +├── tsconfig.json +└── tslint.json +``` + +Run: + +- `nx test shared-components` to test the library +- `nx lint shared-components` to lint the library + +## Using the Library in an Application + +You can import the shared-components library into the Next.js application like this. + +```typescript jsx +import { Home } from '@happynrwl/shared-components'; +import React from 'react'; + +export const Index = () => { + return ( + <> + +
the rest of the component
+ + ); +}; + +export default Index; +``` + +## Sharing Code + +Without Nx, creating a new shared library can take from several hours or 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 components between multiple Next.js applications. You can also share web components between Next.js and plain React applications. You can even share code between the backend and the frontend. All can be done without any unnecessary ceremony. + +## Deploying to Vercel + +You may know that the company behind Next.js, Vercel, has a great hosting platform offering that is developed in tandem with Next.js itself to offer a great overall developer and user experience. + +In order to deploy your Next.js application from your Nx workspace you should do the following: + +### Verify the project's next.config.js + +Let's continue to use our `tuskdesk` example from above, and so we need to check out our config at `apps/tuskdesk/next.config.js`. If you created the application using a recent (at the time of writing) version of Nx, such as Nx 11, then you will likely see the following in that config by default: + +```js +// eslint-disable-next-line @typescript-eslint/no-var-requires +const withNx = require('@nrwl/next/plugins/with-nx'); + +module.exports = withNx({}); +``` + +If you have a config which looks like that (leveraging the `withNx()` config plugin) **AND** the version of Nx you are using is `11.1.0` or later, **no further action is needed** in your config. + +If, however, you created the application using an older version of Nx, you may just see an empty object: + +```js +module.exports = {}; +``` + +If this is the case, or if you are using a version of Nx older than `11.1.0`, then you must do one of the following: + +[Option 1] We would naturally highly recommend upgrading to the latest Nx (for many reasons), and updating the next.config.js to match the first example which leverages the `withNx()` config plugin (which as of `11.1.0` sets target to `'experimental-serverless-trace'` behind the scenes for Vercel builds). + +[Option 2] If for some reason you cannot upgrade to a version of Nx which provides the updated `withNx()` config plugin, you can manually add a `target` property to your exported config with a value of `'experimental-serverless-trace'`. + +E.g. + +```js +// eslint-disable-next-line @typescript-eslint/no-var-requires +const withNx = require('@nrwl/next/plugins/with-nx'); + +module.exports = withNx({ + target: 'experimental-serverless-trace', + // ...You can of course have other Next.js config options specified here too, but the "target" is critical for Vercel deployments... +}); +``` + +OR + +```js +module.exports = { + target: 'experimental-serverless-trace', + // ...You can of course have other Next.js config options specified here too, but the "target" is critical for Vercel deployments... +}; +``` + +> Vercel themselves have informed us that this target will not be required in future versions of Next.js and their platform, but that even when that is the case this option will not cause any issues, so we do not need to worry too much about the name containing "experimental". + +### 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 our `tuskdesk` project the value will look like this: + +```sh +npx nx build tuskdesk --prod --outputPath=. +``` + +4. Leave the "Output Directory" option untouched (i.e. do not toggle the override) + +> You may be thinking, why don't we just override the Output Directory on Vercel and not set the custom `--outputPath` on the build command? At the time of writing these two things are not equivalent to the Vercel build executor that runs behind the scenes, so setting the `--outputPath` is the most appropriate option. + +Therefore, our full configuration (based on a repo called "nx-workspace" and a project called "tuskdesk") will look like this: + +![image](https://user-images.githubusercontent.com/900523/104120015-1253c880-534d-11eb-860f-17e756904448.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: + +![image](https://user-images.githubusercontent.com/900523/104119928-72963a80-534c-11eb-9f0d-e7b4311a22e5.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/data-access-documents/src/data/11.4.0/react/guides/storybook-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/storybook-plugin.md new file mode 100644 index 0000000000..670787b8ff --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/guides/storybook-plugin.md @@ -0,0 +1,364 @@ +# Storybook + +![Storybook logo](/shared/storybook-logo.png) + +Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components. + +## How to Use Storybook in an Nx Repo + +### Add the Storybook plugin + +```bash +yarn add --dev @nrwl/storybook +``` + +### Generating Storybook Configuration + +You can generate Storybook configuration for an individual project with this command: + +```bash +nx g @nrwl/react:storybook-configuration project-name +``` + +If there's no `.storybook` folder at the root of the workspace, one is created. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── apps/ +├── libs/ +├── nx.json +├── package.json +├── README.md +└── etc... +``` + +Also, a project-specific `.storybook` folder is added in the root of the project. + +```treeview +/ +├── .storybook/ +│   ├── main.js +│   ├── config.js +│   ├── tsconfig.json +│   └── webpack.config.js +├── src/ +├── README.md +├── tsconfig.json +└── etc... +``` + +### Running Storybook + +Serve Storybook using this command: + +```bash +nx run project-name:storybook +``` + +### Run Cypress Tests Against a Storybook Instance + +Both `storybook-configuration` generator gives the option to set up an e2e Cypress app that is configured to run against the project's Storybook instance. + +To launch Storybook and run the Cypress tests against the iframe inside of Storybook: + +```bash +nx run project-name-e2e:e2e +``` + +The url that Cypress points to should look like this: + +`'/iframe.html?id=buttoncomponent--primary&knob-text=Click me!&knob-padding&knob-style=default'` + +- `buttoncomponent` is a lowercase version of the `Title` in the `*.stories.ts` file. +- `primary` is the name of an individual story. +- `knob-style=default` sets the `style` knob to a value of `default`. + +Changing knobs in the url query parameters allows your Cypress tests to test different configurations of your component. + +### Example Files + +**\*.stories.tsx file** + +```typescript +import React from 'react'; +import { text, number } from '@storybook/addon-knobs'; +import { Button } from './button'; + +export default { title: 'Button' }; + +export const primary = () => ( + + + ); +}; + +export default App; +``` + +The tests should pass now. + +!!!!! +What will you see if you run: `npx nx e2e todos-e2e --headless` +!!!!! +Cypress will run in the headless mode, and the test will pass. +Cypress will run in the headless mode, and the test will fail. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/04-connect-to-api.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/04-connect-to-api.md new file mode 100644 index 0000000000..f6ac37073f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/04-connect-to-api.md @@ -0,0 +1,61 @@ +# React Nx Tutorial - Step 4: Connect to an API + +## Nx.dev Tutorial | React | 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. + +**Let's change our application to fetch the data from the API.** + +```typescript jsx +import React, { useEffect, useState } from 'react'; + +interface Todo { + title: string; +} + +const App = () => { + const [todos, setTodos] = useState([]); + + useEffect(() => { + fetch('/api/todos') + .then((_) => _.json()) + .then(setTodos); + }, []); + + function addTodo() { + fetch('/api/addTodo', { + method: 'POST', + body: '', + }) + .then((_) => _.json()) + .then((newTodo) => { + setTodos([...todos, newTodo]); + }); + } + + return ( + <> +

Todos

+
    + {todos.map((t) => ( +
  • {t.title}
    • + ))} +
+ + + ); +}; + +export default App; +``` + +!!!!! +Run `npx nx serve todos` and open http://localhost:4200. What do you see? +!!!!! +"the server responded with a status of 404 (Not Found)" in Console. +Blank screen. +Exception rendered on the screen. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/05-add-node-app.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/05-add-node-app.md new file mode 100644 index 0000000000..7384897413 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/05-add-node-app.md @@ -0,0 +1,158 @@ +# React Nx Tutorial - Step 5: Add Node Application Implementing API + +## Nx.dev Tutorial | React | Step 5: Add Node Application Implementing API + + + +The requests fail because the API has not been created yet. Using Nx you can develop node applications next to your React 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 Express Plugin to Your Workspace + +Nx is an open platform with plugins for many modern tools and frameworks. **To see some plugins, run `npx nx list`:** + +```bash +> NX Installed plugins: + + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/linter (builders) + @nrwl/react (schematics) + @nrwl/web (builders,schematics) + @nrwl/workspace (builders,schematics) + + +> NX Also available: + + @nrwl/angular (schematics) + @nrwl/express (builders,schematics) + @nrwl/nest (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-plugin (builders,schematics) + @nrwl/storybook (builders,schematics) + + +> NX Community plugins: + + @nxtend/ionic-react - An Nx plugin for developing Ionic React applications and libraries + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + ... +``` + +**Now run `npx nx list @nrwl/express`, and you will see:** + +```bash +> NX NOTE @nrwl/express is not currently installed + + Use "yarn add --dev @nrwl/express" to add new capabilities +``` + +**Add the dependency:** + +```bash +npm install --save-dev @nrwl/express +``` + +or + +```bash +yarn add --dev @nrwl/express +``` + +> `@nrwl/express` also added `@nrwl/node`. Run `npx nx list @nrwl/express` and `npx nx list @nrwl/node` to see what those plugins provide. + +## Generate an Express Application + +**Run the following to generate a new Express application:** + +```bash +npx nx g @nrwl/express:app api --frontendProject=todos +``` + +After this is done, you should see something like this: + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +│      ├── src/ +│      │   ├── app/ +│      │   ├── 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/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.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 + +**Add a file `apps/api/src/app/todos.ts`.** + +```typescript +import { Express } from 'express'; + +interface Todo { + title: string; +} + +const todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; + +export function addTodoRoutes(app: Express) { + app.get('/api/todos', (req, resp) => resp.send(todos)); + app.post('/api/addTodo', (req, resp) => { + const newTodo = { + title: `New todo ${Math.floor(Math.random() * 1000)}`, + }; + todos.push(newTodo); + resp.send(newTodo); + }); +} +``` + +Here, you are building an Express application with Nx. Nx also comes with Nest support, and you can also use any other node library you want. + +**Next update `apps/api/src/main.ts` to register the routes** + +```typescript +import * as express from 'express'; +import { addTodoRoutes } from './app/todos'; + +const app = express(); + +app.get('/api', (req, res) => { + res.send({ message: 'Welcome to api!' }); +}); +addTodoRoutes(app); + +const port = process.env.port || 3333; +const server = app.listen(port, () => { + console.log(`Listening at http://localhost:${port}/api`); +}); +server.on('error', console.error); +``` + +!!!!! +Run "npx nx serve api" and open http://localhost:3333/api/todos. What do you see? +!!!!! +`[{"title":"Todo 1"},{"title":"Todo 2"}]` +Blank screen +404 diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/06-proxy.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/06-proxy.md new file mode 100644 index 0000000000..bd49864b6c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/06-proxy.md @@ -0,0 +1,84 @@ +# React Nx Tutorial - Step 6: Proxy + +## Nx.dev Tutorial | React | 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 React application to talk to the API in development. + +**To see how it works, open `workspace.json` and find the `serve` target of the todos app.** + +```json +{ + "serve": { + "builder": "@nrwl/web:dev-server", + "options": { + "buildTarget": "todos:build", + "proxyConfig": "apps/todos/proxy.conf.json" + }, + "configurations": { + "production": { + "buildTarget": "todos:build:production" + } + } + } +} +``` + +**Note the `proxyConfig` property.** + +**Now open `proxy.conf.json`:** + +```json +{ + "/api": { + "target": "http://localhost:3333", + "secure": false + } +} +``` + +This configuration tells `npx nx serve` to forward all requests starting with `/api` to the process listening on port 3333. + +## Workspace.json, Targets, Builders + +You configure your workspaces in `workspace.json`. This file contains the workspace projects with their architect targets. For instance, `todos` has the `build`, `serve`, `lint`, and `test` targets. This means that you can run `npx nx build todos`, `npx nx serve todos`, etc.. + +Every target uses a builder which actually runs this target. So targets are analogous to typed npm scripts, and builders are analogous to typed shell scripts. + +**Why not use shell scripts and npm scripts directly?** + +There are a lot of advantages to providing additional metadata to the build tool. For instance, you can introspect targets. `npx nx serve todos --help` results in: + +```bash +npx nx run todos:serve [options,...] + +Options: + --buildTarget Target which builds the application` + --port Port to listen on. (default: 4200) + --host Host to listen on. (default: localhost) + --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) + --liveReload Whether to reload the page on change, using live-reload. (default: true) + --publicHost Public URL where the application will be served + --open Open the application in the browser. + --allowedHosts This option allows you to whitelist services that are allowed to access the dev server. + --memoryLimit Memory limit for type checking service process in MB. + --maxWorkers Number of workers to use for type checking. + --help Show available options for project target. +``` + +It helps with good editor integration (see [VSCode Support](https://nx.dev/react/getting-started/console)). + +But, most importantly, it provides a holistic dev experience regardless of the tools used, and enables advanced build features like distributed computation caching and distributed builds). + +!!!!! +Now run both "npx nx serve todos" and "npx nx serve api" in separate terminals, open http://localhost:4200. What do you see? +!!!!! +Todos application is working! +404 in the console +Todos are displayed but the Add Todo button doesn't work diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/07-share-code.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/07-share-code.md new file mode 100644 index 0000000000..14cb6fcc51 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/07-share-code.md @@ -0,0 +1,95 @@ +# React Nx Tutorial - Step 7: Share Code + +## Nx.dev Tutorial | React | 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 generator 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.ts +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.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 recognised. This may need to be done **every time a new workspace library is added**. + +## Refactor the API + +**Now update `apps/api/src/app/todos.ts` to import the interface:** + +```typescript +import { Express } from 'express'; +import { Todo } from '@myorg/data'; + +const todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; + +export function addTodoRoutes(app: Express) { + app.get('/api/todos', (req, resp) => resp.send(todos)); + app.post('/api/addTodo', (req, resp) => { + const newTodo = { + title: `New todo ${Math.floor(Math.random() * 1000)}`, + }; + todos.push(newTodo); + resp.send(newTodo); + }); +} +``` + +## Update the React Application + +**Next import the interface in `apps/todos/src/app/app.tsx`:** + +```typescript jsx +import React, { useEffect, useState } from 'react'; +import { Todo } from '@myorg/data'; + +export const App = () => { + ... +}; + +export default App; +``` + +Every time you add a new library, you have to restart `npx nx serve`. **So restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +!!!!! +Nx allows you to share code... +!!!!! +Between frontend and backend apps +Between different frontend apps +Between different node apps diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/08-create-libs.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/08-create-libs.md new file mode 100644 index 0000000000..8ec318a9d3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/08-create-libs.md @@ -0,0 +1,182 @@ +# React Nx Tutorial - Step 8: Create Libs + +## Nx.dev Tutorial | React | 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 React components. + +Run + +```bash +npx nx g @nrwl/react:lib ui +``` + +You should see the following: + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +├── libs/ +│   ├── data/ +│ └── ui/ +│      ├── src/ +│      │   ├── lib/ +│      │   │ └── ui/ +│      │   │ ├── ui.css +│      │   │ ├── ui.spec.tsx +│      │   │ └── ui.tsx +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── nx.json +├── package.json +└── tsconfig.json +``` + +The `libs/ui/src/lib/ui.tsx` file looks like this: + +```typescript jsx +import React from 'react'; + +import './ui.css'; + +export interface UiProps {} + +export const Ui = (props: UiProps) => { + return ( +
+

Welcome to ui!

+
+ ); +}; + +export default Ui; +``` + +## Add a Component + +Here, you can either change the UI component or generate a new one. + +**Add a component to the newly created ui library by running:** + +```bash +npx nx g @nrwl/react:component todos --project=ui --export +``` + +```treeview +myorg/ +├── apps/ +│   ├── todos/ +│   ├── todos-e2e/ +│   └── api/ +├── libs/ +│   ├── data/ +│ └── ui/ +│      ├── src/ +│      │   ├── lib/ +│      │   │ ├── ui/ +│      │   │ │ ├── ui.css +│      │   │ │ ├── ui.spec.tsx +│      │   │ │ └── ui.tsx +│      │   │ └── todos/ +│      │   │ ├── todos.css +│      │   │ ├── todos.spec.tsx +│      │   │ └── todos.tsx +│      │   └── index.ts +│      ├── jest.conf.js +│      ├── tsconfig.app.json +│      ├── tsconfig.json +│      └── tsconfig.spec.json +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +**Implement the Todos component.** + +```typescript jsx +import React from 'react'; +import { Todo } from '@myorg/data'; + +export const Todos = (props: { todos: Todo[] }) => { + return ( +
    + {props.todos.map((t) => ( +
  • {t.title}
    • + ))} +
+ ); +}; + +export default Todos; +``` + +## Use the UI Library + +**Now import `Todos` into `apps/todos/src/app/app.tsx`.** + +```typescript +import React, { useEffect, useState } from 'react'; +import { Todo } from '@myorg/data'; +import { Todos } from '@myorg/ui'; + +const App = () => { + const [todos, setTodos] = useState([]); + + useEffect(() => { + fetch('/api/todos') + .then((_) => _.json()) + .then(setTodos); + }, []); + + function addTodo() { + fetch('/api/addTodo', { + method: 'POST', + body: '', + }) + .then((_) => _.json()) + .then((newTodo) => { + setTodos([...todos, newTodo]); + }); + } + + return ( + <> +

Todos

+ + + + ); +}; + +export default App; +``` + +**Restart both `npx nx serve api` and `npx nx serve todos` and you should see the application running.** + +> Nx helps you explore code generation options. Run `npx nx g @nrwl/react:component --help` to see all options available. Pass `--dry-run` to the command to see what would be generated without actually changing anything, like this: `npx nx g @nrwl/react:component mycmp --project=ui --dry-run`. + +!!!!! +Libraries' public API is defined in... +!!!!! +index.ts +workspace.json and tsconfig.json files diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/09-dep-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/09-dep-graph.md new file mode 100644 index 0000000000..1d214ea01a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/09-dep-graph.md @@ -0,0 +1,18 @@ +# React Nx Tutorial - Step 9: Dep Graph + +## Nx.dev Tutorial | React | Step 9: Dep Graph + + + +An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it can be 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 "npx nx dep-graph". What do you see? +!!!!! +A dependency diagram in the browser +A dep-graph.html file created at the root of the workspace +A json document printed out in the terminal diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/10-computation-caching.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/10-computation-caching.md new file mode 100644 index 0000000000..4ddf9028a6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/10-computation-caching.md @@ -0,0 +1,103 @@ +# React Nx Tutorial - Step 10: Computation Caching + +## Nx.dev Tutorial | React | 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 +> npx nx run todos:build + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: c38fbdb8b372af447180 +Built at: 03/26/2020 11:03:57 AM +Entrypoint main = runtime.ff0534391bf88384547e.js main.b8dbcd3d3fd2900377f2.esm.js +Entrypoint polyfills = runtime.ff0534391bf88384547e.js polyfills.55535a35b1529d884ca3.esm.js +Entrypoint styles = runtime.ff0534391bf88384547e.js styles.3ff695c00d717f2d2a11.css +chunk {0} runtime.ff0534391bf88384547e.js (runtime) 0 bytes ={1}= ={2}= ={3}= [entry] [rendered] +chunk {1} main.b8dbcd3d3fd2900377f2.esm.js (main) 155 KiB ={0}= [initial] [rendered] +chunk {2} polyfills.55535a35b1529d884ca3.esm.js (polyfills) 239 KiB ={0}= [initial] [rendered] +chunk {3} styles.3ff695c00d717f2d2a11.css (styles) 147 bytes ={0}= [initial] [rendered] +``` + +**Now, run `npx nx build todos` again, and you will see the results appearing instantly:** + +```bash +> npx nx run todos:build + +> NX NOTE Cached Output: + +Starting type checking service... +Using 14 workers with 2048MB memory limit +Hash: c38fbdb8b372af447180 +Built at: 03/26/2020 11:05:06 AM +Entrypoint main = runtime.ff0534391bf88384547e.js main.b8dbcd3d3fd2900377f2.esm.js +Entrypoint polyfills = runtime.ff0534391bf88384547e.js polyfills.55535a35b1529d884ca3.esm.js +Entrypoint styles = runtime.ff0534391bf88384547e.js styles.3ff695c00d717f2d2a11.css +chunk {0} runtime.ff0534391bf88384547e.js (runtime) 0 bytes ={1}= ={2}= ={3}= [entry] [rendered] +chunk {1} main.b8dbcd3d3fd2900377f2.esm.js (main) 155 KiB ={0}= [initial] [rendered] +chunk {2} polyfills.55535a35b1529d884ca3.esm.js (polyfills) 239 KiB ={0}= [initial] [rendered] +chunk {3} styles.3ff695c00d717f2d2a11.css (styles) 147 bytes ={0}= [initial] [rendered] +``` + +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. + +## Building Multiple Projects + +**Now, run `npx nx run-many --target=build --projects=todos,api` to rebuild the two applications:** + +```bash +Nx read the output from cache instead of running the command for 1 out of 2 projects. +``` + +Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache [here](/{{framework}}/core-concepts/computation-caching). + +## --with-deps + +As we saw already, Nx is smart, so it knows how applications and libraries in the workspace depend on each other. + +**Run `npx nx lint todos --with-deps`, and you see that Nx lints both the `todos` app and the libraries it depends on.** + +```bash +> NX Running target lint for project todos and its 2 deps. + +——————————————————————————————————————————————— + +> npx nx run todos:lint + +Linting "todos"... + +All files pass linting. + + +> npx nx run ui:lint + +Linting "ui"... + +All files pass linting. + + +> npx nx run data:lint + +Linting "data"... + +All files pass linting. + + +——————————————————————————————————————————————— + +> NX SUCCESS Running target "lint" succeeded +``` + +> Add --parallel to any command, and Nx will do most of the work in parallel. + +!!!!! +Run `npx nx lint api --with-deps`. What do you see? +!!!!! +Nx read the output from cache instead of running the command for 1 out of 2 projects. +Everything was retrieved from the cache +`Cannot lint data` error diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/11-test-affected-projects.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/11-test-affected-projects.md new file mode 100644 index 0000000000..726463b696 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/11-test-affected-projects.md @@ -0,0 +1,78 @@ +# React Nx Tutorial - Step 11: Test Affected Projects + +## Nx.dev Tutorial | React | Step 11: Test Affected Projects + + + +In addition to supporting computation caching, Nx can scale your development by doing code change analysis to see what can affected by a particular pull request. + +**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.tsx` and change the component:** + +```typescript jsx +import React from 'react'; +import { Todo } from '@myorg/data'; + +export const Todos = (props: { todos: Todo[] }) => { + return ( +
    + {props.todos.map((t) => ( +
  • {t.title}!!
    • + ))} +
+ ); +}; + +export default Todos; +``` + +**Run `npx nx affected:apps`**, and you should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the dependency graph to figure out which apps can be affected by this change. + +**Run `npx nx affected:libs`**, and 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 `npx nx affected:test` to retest only the projects affected by the change.** + +As you can see, since we updated the code, without updating the tests, the unit tests failed. + +```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. + +## 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 +``` + +!!!!! +Run "npx nx affected --target=invalid --base=master". What do you see? +!!!!! +No projects with "invalid" were run +An error message saying that the "invalid" target is invalid diff --git a/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/12-summary.md b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/12-summary.md new file mode 100644 index 0000000000..a0c3a78f67 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/react/tutorial/12-summary.md @@ -0,0 +1,18 @@ +# React Nx Tutorial - Step 12: Summary + +In this tutorial you: + +- Built a full stack application using React and Express +- Shared code between the frontend and the backend +- Created a UI library +- Used Nx dep graph capabilities 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](/{{framework}}/getting-started/cli-overview) +- [Computation Caching](/{{framework}}/core-concepts/computation-caching) +- [Rebuilding What is Affected](/{{framework}}/core-concepts/affected) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.md new file mode 100644 index 0000000000..6ef0f1e58c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.md @@ -0,0 +1,194 @@ +# Rebuilding and Retesting What is Affected + +When using Nx you can build and test individual apps and libs. + +```bash +nx g @nrwl/web:app client +nx g @nrwl/web:app admin +nx g @nrwl/workspace:lib client-feature-main +nx g @nrwl/workspace:lib admin-feature-permissions +nx g @nrwl/workspace:lib components-shared + +nx build client +nx build client-feature-main # works if the lib is marked as publishable + +nx test client +nx test admin +nx test client-feature-main +nx e2e client-e2e +``` + +Now imagine, `admin` depends on `admin-feature-permissions`. If we make a change to `admin-feature-permissions`, we not only need to make sure that `admin-feature-permissions` still functions as intended. We also need to make sure nothing that depends on `admin-feature-permissions` such as `admin` is broken unintentionally. + +Typically, you would do it like this: + +```bash +nx test admin-feature-permissions +nx build admin +nx test admin +nx e2e admin-e2e +``` + +In many organizations, you would have dozens or hundreds of apps and libs. To be productive in a monorepo, you need to be able to check that your change is safe, and rebuilding and retesting everything on every change won't scale, tracing the dependencies manually (as shown above) won't scale either. + +Because Nx has built-in computation caching, you could retest and rebuild everything on every commit: + +```bash +nx run-many --target=test --all +nx run-many --target=lint --all +nx run-many --target=e2e --all +nx run-many --target=build --all +``` + +If you use [Nx Cloud](https://nx.app), this can be a viable option. + +## Code Changes Analysis + +In addition to computation caching, Nx supports code change analysis. Nx uses code analysis to construct a dependency graph of all projects in the workspace. It then uses the dependency graph to determine what needs to be rebuilt and retested based on what you changed in a git branch. + +## Viewing Dep Graph + +Run `nx dep-graph` to see the dependency graph. + +![dependency-graph](/shared/dependency-graph.png) + +## Affected + +Affected projects are projects that are impacted by a set of changes. In order to find out which projects could be impacted by a particular change, Nx first determines which projects own the changed files. These projects are definitely impacted because they had changes made directly to them. Projects that consume projects which are directly changed may also be impacted by these changes. As a result, those projects must be tested as well to verify that all changes in behavior are identified. + +To calculate the project affected by your change, Nx needs to know what file you changed. The most direct way to do it is by passing `--files`: + +```bash +nx affected:dep-graph --files=libs/admin-feature-permissions/src/index.ts +``` + +![dependency-graph-affected](/shared/affected.png) + +In practice, it's easier to use git to determine what files have changed. + +```bash +nx affected:dep-graph --base=master --head=HEAD +``` + +The `--base` defaults to `master` and `--head` defaults to `HEAD`, so when running it locally you can usually omit it: + +```bash +nx affected:dep-graph +``` + +Nx will find the most common ancestor of the base and head SHAs and will use it to determine what has changed between it and head. + +## Building/Testing/Printing Affected Projects + +```bash +nx affected:apps # prints affected apps +nx affected:libs # prints affected libs +nx affected:build # builds affected apps and libs +nx affected:lint # lints affected apps and libs +nx affected:test # tests affected apps and libs +nx affected:e2e # e2e tests affected apps +``` + +All of these are just shortcuts for the following: + +```bash +nx affected --target=ANYTARGET # run ANYTARGET for all affected apps and libs +``` + +## CI + +The SHAs you pass must be defined in the git repository. The `master` and `HEAD` SHAs are what you normally use while developing. Most likely you will want to provision other SHAs in your CI environment. + +```bash +nx affected:build --base=origin/master --head=$PR_BRANCH_NAME # where PR_BRANCH_NAME is defined by your CI system +nx affected:build --base=origin/master~1 --head=origin/master # rerun what is affected by the last commit in master +``` + +## When Nx can't Understand Your Repository + +Nx uses its advanced code analysis to construct a dependency graph of all applications and libraries. Some dependencies, however, cannot be determined statically. But you can define them yourself in `nx.json`. + +```json +{ + "npmScope": "myorg", + "implicitDependencies": { + "package.json": "*", + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "client": { + "tags": [], + "implicitDependencies": [] + }, + "client-e2e": { + "tags": [], + "implicitDependencies": ["client"] + }, + "admin": { + "tags": [], + "implicitDependencies": [] + }, + "admin-e2e": { + "tags": [], + "implicitDependencies": ["admin"] + }, + "client-feature-main": { + "tags": [], + "implicitDependencies": [] + }, + "admin-feature-permissions": { + "tags": [], + "implicitDependencies": [] + }, + "components-shared": { + "tags": [], + "implicitDependencies": [] + } + } +} +``` + +The `implicitDependencies` map is used to define what projects are affected by global files. In this example, any change to `package.json` will affect all the projects in the workspace, so all of them will have to be rebuilt and retested. You can replace `*` with an explicit list of projects. + +```json +{ + "implicitDependencies": { + "package.json": ["admin", "client"], + "tsconfig.json": "*", + "nx.json": "*" + } +} +``` + +You can also specify dependencies between projects. For instance, if `admin-e2e` tests both the `admin` and `client` applications, you can express this as follows: + +```json +{ + "admin-e2e": { + "tags": [], + "implicitDependencies": ["client", "admin"] + } +} +``` + +### Ignoring Additional Files from Affected Commands + +Nx provides two methods to exclude additional glob patterns (files and folders) from `affected:*` commands. + +- Glob patterns defined in your `.gitignore` file are ignored. +- Glob patterns defined in an optional `.nxignore` file are ignored. + +## Caching and Affected + +Affected and caching are used to solve the same problem: minimize the computation. But they do it differently, and the combination provides better results than one or the other. + +The affected command looks at the before and after states of the workspaces and figures out what can be broken by a change. Because it knows the two states, it can deduce the nature of the change. For instance, this repository uses React and Angular. If a PR updates the version of React in the root package.json, Nx will know that only half of the projects in the workspace can be affected. It knows what was changed--the version of React was bumped up. + +Caching simply looks at the current state of the workspace and the environment (e.g., version of Node) and checks if somebody already ran the command against this state. Caching knows that something changed, but because there is no before and after states, it doesn't know the nature of the change. In other words, caching is a lot more conservative. + +If we only use affected, the list of projects that will be retested is small, but if we test the PR twice, we will run all the tests twice. + +If we only use caching, the list of projects that will be retested is larger, but if we test the PR twice, we will only run tests the first time. + +Using both allows us to get the best of both worlds. The list of affected projects is as small as it can be, and we never run anything twice. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.png new file mode 100644 index 0000000000..4437f9a8e3 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/affected.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/all-cache-inputs.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/all-cache-inputs.png new file mode 100644 index 0000000000..e7e5bd839e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/all-cache-inputs.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/angular-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/angular-plugin.md new file mode 100644 index 0000000000..849e3bd5b9 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/angular-plugin.md @@ -0,0 +1,112 @@ +# Angular Plugin + +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 Jest, Cypress, Karma, Protractor, and Storybook. +- Helper services, and functions to use along with NgRx libraries. +- Scaffolding for upgrading AngularJS applications. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the Angular plugin + +Adding the Angular plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/angular +``` + +```shell script +#npm +npm install -D @nrwl/angular +``` + +## Angular Projects in an Nx Workspace + +Building Angular applications within an Nx workspace is similar to building within a vanilla Angular CLI workspace, with a few differences. + +- Jest is used as the default unit test runner, configurable in the generators section of the workspace configuration file. +- Cypress is used as the default E2E test runner, configurable in the generators section of the workspace configuration. +- E2E tests are included in a separate project from the Angular application itself. +- The Nx CLI delegates common commands such as build, serve, test, lint, and e2e to the Angular CLI. + +The file structure for an Angular application looks like: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.ts +│   │   │   ├── polyfills.ts +│   │   │   ├── styles.scss +│   │   │   └── test.ts +│   │   ├── browserslist +│   │   ├── jest.conf.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── tslint.json +│   └── myapp-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      ├── tsconfig.json +│      └── tslint.json +├── libs/ +├── tools/ +├── angular.json +├── nx.json +├── package.json +├── tsconfig.json +├── tslint.json +└── README.md +``` + +## See Also + +- [Using DataPersistence](/angular/guides/misc-data-persistence) +- [Using NgRx](/angular/guides/misc-ngrx) +- [Upgrading an AngularJS application to Angular](/angular/guides/misc-upgrade) + +## Executors / Builders + +- [package](/{{framework}}/angular/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Generators + +- [application](/{{framework}}/angular/application) - Create an Angular application +- [downgrade-module](/{{framework}}/angular/downgrade-module) - Setup Downgrade Module +- [karma](/{{framework}}/angular/karma) - Add karma configuration to a workspace +- [karma-project](/{{framework}}/angular/karma-project) - Add karma testing to a project +- [library](/{{framework}}/angular/library) - Create an Angular library +- [move](/{{framework}}/angular/move) - Move an Angular application or library to another folder within the workspace +- [ngrx](/{{framework}}/angular/ngrx) - Add and use NgRx for state management +- [stories](/{{framework}}/angular/stories) - Create stories/specs for all components declared in a library +- [storybook-configuration](/{{framework}}/angular/storybook-configuration) - Setup configuration for Storybook +- [upgrade-module](/{{framework}}/angular/upgrade-module) - Add an upgrade module + +## Public API + +- DataPersistence - Angular Service that provides convenience methods for common operations of persisting data. +- fetch - Handles data fetching, and correct ordering of fetching using NgRx Effects +- navigation - Handles data fetching based on navigating to a certain component using NgRx Effects +- optimisticUpdate - Handles optimistic updates (updating the client first) using NgRx Effects. +- pessimisticUpdate - Handles pessimistic updates (updating the server first) fetching using NgRx Effects. + NxModule - An NgModule used to register the Angular providers, including DataPersistence. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/angular.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/angular.jpg new file mode 100644 index 0000000000..f03bf78a3b Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/angular.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/cypress.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/cypress.jpg new file mode 100644 index 0000000000..7727bf6d73 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/cypress.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/express.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/express.jpg new file mode 100644 index 0000000000..f55f7f0783 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/express.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/jest.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/jest.jpg new file mode 100644 index 0000000000..d7ce915a2a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/jest.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/nest.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/nest.jpg new file mode 100644 index 0000000000..9e02b1e3dd Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/nest.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/node.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/node.jpg new file mode 100644 index 0000000000..7003802217 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/node.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/react.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/react.jpg new file mode 100644 index 0000000000..e534bd5b24 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/react.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/api/web.jpg b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/web.jpg new file mode 100644 index 0000000000..d92cea331c Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/api/web.jpg differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/caching-example.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/caching-example.png new file mode 100644 index 0000000000..026252539a Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/caching-example.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-everything-affected.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-everything-affected.png new file mode 100644 index 0000000000..95ea861c4e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-everything-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-one-affected.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-one-affected.png new file mode 100644 index 0000000000..1eb5a4c166 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph-one-affected.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph.png new file mode 100644 index 0000000000..94138839ea Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/ci-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/build.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/build.md new file mode 100644 index 0000000000..8a398ba7e3 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/build.md @@ -0,0 +1,294 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx build [options] +``` + +```bash +nx run :build [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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 https://webpack.github.io/ +analyse. + +### 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/data-access-documents/src/data/11.4.0/shared/cli/e2e.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/e2e.md new file mode 100644 index 0000000000..279449cf40 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/e2e.md @@ -0,0 +1,151 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx e2e +``` + +```bash +nx run :e2e +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc options are listed below. + +### baseUrl + +Use this to pass directly the address of your distant server address with the port running your application. + +### 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/data-access-documents/src/data/11.4.0/shared/cli/generate.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/generate.md new file mode 100644 index 0000000000..0fa39dc3f6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/generate.md @@ -0,0 +1,93 @@ +# 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 the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/shared/cli/lint.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/lint.md new file mode 100644 index 0000000000..19efd0e2af --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/lint.md @@ -0,0 +1,105 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx lint [options] +``` + +```bash +nx run :lint [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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/data-access-documents/src/data/11.4.0/shared/cli/run.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/run.md new file mode 100644 index 0000000000..87df36051c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/run.md @@ -0,0 +1,39 @@ +# run + +Runs an Architect target with an optional custom builder configuration defined in your project. + +## Usage + +```bash +nx run [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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/data-access-documents/src/data/11.4.0/shared/cli/serve.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/serve.md new file mode 100644 index 0000000000..6a87bc9776 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/serve.md @@ -0,0 +1,199 @@ +# serve + +Builds and serves an application, rebuilding on file changes. + +## Usage + +The `serve` command is a built-in alias to the [run command](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx serve [options] +``` + +```bash +nx run :serve [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc serve options are listed after these options. + +### allowedHosts + +This option allows you to whitelist services that are allowed to access the dev server. + +### 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 + +Enable hot module replacement. + +### 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/data-access-documents/src/data/11.4.0/shared/cli/test.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/test.md new file mode 100644 index 0000000000..84d7e9db86 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cli/test.md @@ -0,0 +1,258 @@ +# 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](/{{framework}}/cli/run). + +These two commands are equivalent: + +```bash +nx test [options] +``` + +```bash +nx run :test [options] +``` + +Install the `nx` package globally to invoke the command directly using `nx`, or use `npm run nx` or `yarn 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-specifc 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. + +### tsCconfig + +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/data-access-documents/src/data/11.4.0/shared/computation-caching.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/computation-caching.md new file mode 100644 index 0000000000..ad15e517a8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/computation-caching.md @@ -0,0 +1,188 @@ +# Computation Caching + +It's costly to rebuild and retest the same code over and over again. Nx uses a computation cache to never rebuild the same code twice. When connected to Nx cloud, you can share the computation cache with everyone working on the same project. + +**In order not to recompute something twice, we need two things:** + +**1. We need to store the results of the computation.** +**2. We need to know when we are about to compute something we already computed before.** + +There are three things that tell Nx if something has been computed before: + +## Source Code Cache Inputs + +The result of building/testing an application or a library depends on the source code of that project and all the source codes of all the libraries it depends on (directly or indirectly). It also depends on the configuration files like `package.json`, `workspace.json`, `nx.json`, `tsconfig.json`, and `package-lock.json`. The list of these files isn't arbitrary. Nx can deduce most of them by analyzing our codebase. Few will have to be listed manually in the `implicitDependencies` property of `nx.json`. + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": { + "global-config-file.json": "*" + }, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"] + } + } + } +} +``` + +## Runtime Cache Inputs + +Things like the version of NodeJS, whether we are running Windows or not, can affect the results of the computation but cannot be deduced statically. Those will have to be configured manually too. + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": {}, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"], + "runtimeCacheInputs": ["node -v", "echo $IMPORTANT_ENV_VAR"] + } + } + } +} +``` + +## Args Cache Inputs + +Finally, in addition to Source Code Cache Inputs and Runtime Cache Inputs, Nx needs to consider the arguments. I.e., `nx build shop` and `nx build shop --prod` produce different results. + +Note, only the flags passed to the builder itself affect results of the computation. For instance, the following commands are identical from the caching perspective. + +```bash +nx build myapp --prod +nx build myapp --configuration=production +nx run-many --target=build --projects=myapp --configuration=production +nx run-many --target=build --projects=myapp --configuration=production --parallel +nx affected:build # given that myapp is affected +``` + +In other words, Nx does not cache what the developer types into the terminal. The args cache inputs consist of: Project Name, Target, Configuration + Args Passed to Builders. + +If you build/test/lint… multiple projects, each individual build will have its own cache value and will either be retrieved from cache or run. This means that from the caching point of view, the following command: + +```bash +nx run-many --target=build --projects=myapp1,myapp2 +``` + +is identical to the following two commands: + +```bash +nx build myapp1 +nx build myapp2 +``` + +## All Cache Inputs + +So the combination of Source Code Cache Inputs, Runtime Cache Inputs, and Args Cache Inputs determine the result of the computation. If anything in the source changes, Nx needs to recompute. If anything in runtime changes, Nx needs to recompute. But if we have already computed the results, we can simply use the stored artifacts. + +![all cache inputs](/shared/all-cache-inputs.png) + +## What is Cached + +Nx works on the process level. Regardless of the tools used to build/test/lint/etc.. your project, the results will be cached. + +Nx sets up hooks to collect stdout/stderr before running the command. All the output will be cached and then replayed during a cache hit. + +Nx will also cache the files generated by a command. The list of folders is listed in the outputs property in `workspace.json`. + +```json +{ + "projects": { + "myapp": { + "root": "apps/myapp/", + "sourceRoot": "apps/myapp/src", + "projectType": "application", + "architect": { + "build": { + "builder": "@nrwl/web:build", + "outputs": ["dist/apps/myapp"], + "options": { + "index": "apps/myapp/src/app.html", + "main": "apps/myapp/src/main.tsx" + } + } + } + } +} +``` + +If the outputs property is missing, Nx will default to caching the appropriate folder in the dist (`dist/apps/myapp` for `myapp` and `dist/libs/somelib` for `somelib`). + +## Local Computation Memoization + +**Because the word "cache" appears in the description, the phrase "artifact caching" comes to mind. But this isn't the right way to think about it. What Nx does is computation memoization.** We can't choose to use or not use the cached value. There are no versions. It is transparent: Nx will skip the computation only when running the computation would have produced the same result. + +By default, Nx uses a local computation cache. The cache is stored in `node_modules/.cache/nx`. You can change the directory as follows: + +```json +{ + "npmScope": "happyorg", + "implicitDependencies": {}, + "projects": {}, + "tasksRunnerOptions": { + "default": { + "options": { + "cacheableOperations": ["build", "test", "lint", "e2e"], + "cacheDirectory": "/tmp/nx" + } + } + } +} +``` + +Nx stores the cached values only for a week, after which they are deleted. To clear the cache, delete the cache directory, and Nx will create a new one next time it tries to access it. + +## Skipping Cache + +Sometimes you will want to skip the cache (e.g., if you are measuring the performance of a command). You can do it as follows + +```bash +nx build myapp --skip-nx-cache +nx affected:build --skip-nx-cache +``` + +## Nx Cloud and Distributed Computation Memoization + +Nx Cloud is a SAAS product that allows you to share the results of running build/test with everyone else working in the same workspace. Learn more at [https://nx.app](https://nx.app). + +## Example + +Say we are the first ones building some shop app. + +The `nx build` shop command will build the app by invoking webpack under the hood. It will create a hash key using the combination of `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs`. Nx then will check its local cache to see if this combination has already been built on this machine. If the answer is "no", it will check the Nx Cloud cache (if the workspace is connected to it) to see if someone else has already built it. If the answer is "no", it will run the build. + +It will set up hooks to collect stdout/stderr, and once the build is complete, it will store the command line output into a file in the local cache. It will also copy the produced files there as well. After that it will spawn a separate process to upload the artifacts to the Nx Cloud cache. + +If we rerun the same command, Nx will find the artifact in the local cache and will replay the output from it and will restore the necessary files. + +Imagine someone else on the team is trying to build `nx build shop`. As before Nx will use `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs` to get the computation hash key. It will then check the local cache. The result won't be there, so it will check the remote cache. **It will find the record there, so it will download it into its local cache first and then print the stored stdout/stderr and copy the files to the place where they would normally be created. The terminal output and the created files are exactly the same as if the person ran the computation themselves.** + +The "someone else" in this scenario doesn't have to be a real person. For instance, every CI run will likely use a different agent. When the agents can all access the same remote cache, the CI time goes down drastically. + +![cache example](/shared/caching-example.png) + +The `nx test shop` command, which in this case uses Jest, works similarly. The combination of `Source Code Cache Inputs`, `Runtime Cache Inputs`, and `Args Cache Inputs` determines the computation. The command won't emit any files, but the terminal output will be captured and stored. + +## Caching and Affected + +In addition to the memoization, which works against the current state of the codebase and the environment, Nx also is able to look at the code change itself (e.g., PR), and figure out what can be broken by it, and only rebuild and retest what is affected. Why use both? + +Affected and caching are used to solve the same problem: minimize the computation. But they do it differently, and the combination provides better results than one or the other. + +The affected command looks at the before and after states of the workspaces and figures out what can be broken by a change. Because it knows the two states, it can deduce the nature of the change. For instance, this repository uses React and Angular. If a PR updates the version of React in the root package.json, Nx will know that only half of the projects in the workspace can be affected. It knows what was changed--the version of React was bumped up. + +Caching simply looks at the current state of the workspace and the environment (e.g., version of Node) and checks if somebody already ran the command against this state. Caching knows that something changed, but because there is no before and after states, it doesn't know the nature of the change. In other words, caching is a lot more conservative. + +If we only use affected, the list of projects that will be retested is small, but if we test the PR twice, we will run all the tests twice. + +If we only use caching, the list of projects that will be retested is larger, but if we test the PR twice, we will only run tests the first time. + +Using both allows us to get the best of both worlds. The list of affected projects is as small as it can be, and we never run anything twice. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/console.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/console.md new file mode 100644 index 0000000000..87d903638c --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/console.md @@ -0,0 +1,120 @@ +# Nx Console + +![Nx Console logo](/shared/nx-console-logo.png) + +**Spend less time looking up command line arguments and more time shipping incredible products.** + +- [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) + +With Nx, you can get a full-stack application up and running in minutes, no need to figure out source maps, webpack, test runners. It all works out of the box. Nx also helps you enforce consistent development practices by generating components, services, and state management modules. + +## Why Nx Console? + +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 + +For VSCode users, you can install the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) from Marketplace. + +## True UI for Nx + +Nx Console is the UI for Nx. It will work 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, 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 Pallete** + +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 satified with the constructed command, choose the `Execute` command at the top of the list. + + + +### Run + +The `Run` action allows you to choose a builder command and then opens a form listing out all the options for that builder. The frequently used builder commands `build`, `serve`, `test`, `e2e` and `lint` also have their own dedicated actions. + + + +**From the Command Pallete** + +You can also construct the builder 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 builder command options. When you're satified 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 will navigate to that project's definition in the `workspace.json` (or `angular.json`) file. Clicking on the name of any builder command will navigate to that builder command's definition in the `workspace.json` (or `angular.json`) file. + +Clicking the [refresh-light.svg] icon next to the `PROJECTS` header will repopulate the Projects pane from the `workspace.json` (or `angular.json`) file. + +Clicking the [folder-light.svg] icon next to a project will reveal that project's folder in the VSCode Explorer pane. + +Clicking the [continue-light.svg] icon next to a builder command will execute 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/data-access-documents/src/data/11.4.0/shared/continue-light.svg b/nx-dev/data-access-documents/src/data/11.4.0/shared/continue-light.svg new file mode 100644 index 0000000000..2563bfa114 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/continue-light.svg @@ -0,0 +1,3 @@ + + + diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-logo.png new file mode 100644 index 0000000000..6553e4a03e Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-plugin.md new file mode 100644 index 0000000000..0e6ed45540 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/cypress-plugin.md @@ -0,0 +1,92 @@ +# 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 + +## How to Use 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 +``` + +```treeview +/ +├── apps/ +│   ├── frontend/ +│   └── frontend-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── nx.json +├── package.json +├── README.md +├── workspace.json +└── tsconfig.json +``` + +### 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, `ng 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). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/dependency-graph.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/dependency-graph.png new file mode 100644 index 0000000000..7c187112fb Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/dependency-graph.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/devkit.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/devkit.md new file mode 100644 index 0000000000..cbd833639e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/devkit.md @@ -0,0 +1,498 @@ +# Nx Devkit + +Nx is a pluggable build tool, so most of its functionality is provided by plugins. The Nx Devkit is the underlying technology used to customize Nx to support different technologies and your own custom use-cases. + +Plugins have: + +- Generators + - Anytime you run `nx generate ...`, you invoke a generator + - Generators automate making changes to the file system + - They are used to create/update applications, libraries, components, etc.. +- Executors + - Anytime you run `nx run ...` (or `nx test`, `nx build`), you invoke an executor + - Executors define how to perform an action on a project + - They are used to build applications and libraries, test them, lint them, etc.. + +All of the core plugins are written using Nx Devkit and you can use the same utilities to write your own generators and executors. + +## 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](/{{framework}}/core-concepts/nx-devkit#simplest-generator) and [Simplest Executor](/{{framework}}/core-concepts/nx-devkit#simplest-executor). Most of what you will see in this guide are extra affordances -- things that are optional to use, but we found very handy when building plugins. + +## Generators + +Generators automate making file changes for you. They can create new files, overwrite existing files, delete existing files, etc. For example, adding a new application may involve creating numerous files and updating configuration. By providing a generator that creates new applications, you can start coding the interesting parts of their application without having to spend hours setting the project up. + +A generator consists of the following: + +- a schema that describes what can be input into the generator +- the implementation that takes the inputs and makes changes to the file system + +Unlike a naive script which makes changes to the file system, generators update the file system atomically at the end. This means that if an error occurs, the file system is not partially updated. + +### Schema + +A generator's schema describes the inputs--what you can pass into it. The schema is used to validate inputs, to parse args (e.g., covert strings into numbers), to set defaults, and to power the VSCode plugin. It is written with [JSON Schema](https://json-schema.org/). + +#### Examples + +```json +{ + "cli": "nx", + "id": "CustomGenerator", + "description": "Create a custom generator", + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "Generator name", + "x-prompt": "What name would you like to use for the workspace generator?" + }, + "skipFormat": { + "description": "Skip formatting files", + "type": "boolean", + "alias": "sf", + "default": false + } + }, + "required": ["name"] +} +``` + +The schema above defines two fields: `name` and `skipFormat`. The `name` field is a string, `skipFormat` is a boolean. The `x-prompt` property tells Nx to ask for the `name` value if one isn't given. The `skipFormat` field has the default value set to `false`. The schema language is rich and lets you use lists, enums, references, etc.. A few more examples: + +```json +{ + "cli": "nx", + "id": "CustomGenerator", + "description": "Create a custom generator", + "type": "object", + "properties": { + "stringOrBoolean": { + "oneOf": [ + { + "type": "string", + "default": "mystring!" + }, + { + "type": "boolean" + } + ] + }, + "innerObject": { + "type": "object", + "properties": { + "key": { + "type": "boolean" + } + } + }, + "array": { + "type": "array", + "items": { + "type": "number" + } + }, + "complexXPrompt": { + "type": "string", + "default": "css", + "x-prompt": { + "message": "Which stylesheet format would you like to use?", + "type": "list", + "items": [ + { + "value": "css", + "label": "CSS" + }, + { + "value": "scss", + "label": "SASS(.scss)" + }, + { + "value": "styl", + "label": "Stylus(.styl)" + }, + { + "value": "none", + "label": "None" + } + ] + } + }, + "positionalArg": { + "type": "string", + "$default": { + "$source": "argv", + "index": 0 + } + }, + "currentProject": { + "type": "string", + "$default": { + "$source": "projectName" + } + } + } +} +``` + +Sometimes, you may not know the schema or may not care, in this case, you can set the following: + +```json +{ + "cli": "nx", + "id": "CustomGenerator", + "description": "Create a custom generator", + "type": "object", + "properties": { + "name": { + "type": "string" + } + }, + "required": ["name"], + "additionalProperties": true +} +``` + +Because `"additionalProperties"` is `true`, the generator above will accept any extra parameters you pass. They, of course, won't be validated or transformed, but sometimes that's good enough. + +If you want to learn more about the schema language, check out the core plugins at [https://github.com/nrwl/nx](https://github.com/nrwl/nx) for more examples. + +### Implementation + +The implementation is a function that takes two arguments: + +- `tree`: an implementation of the file system + - Allows you to read/write files, list children, etc. + - It's recommended to use the tree instead of directly interacting with the file system + - This enables the `--dry-run` mode so you can try different sets of options before actually making changes to their files. +- `options`: the options that a user passes + - This is described by the schema and allows users to customize the result of the generator to their needs. + +The implementation can return a callback which is invoked _after changes have been made to the file system_. For example, the implementation might add dependencies to `package.json` and install them afterwards. Because installing dependencies requires that the `package.json` has the changes on disk, installing dependencies should be done in the callback returned. + +#### Examples + +```typescript +import { + Tree, + generateFiles, + formatFiles, + installPackagesTask, +} from '@nrwl/devkit'; + +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); + } + + return () => { + installPackagesTask(tree); + }; +} +``` + +The generator is an async function. You could create new projects and generate new files, but you could also update existing files and refactor things. It's recommended to limit all the side-effects to interacting with the tree and printing to the console. Sometimes generators perform other side affects (e.g., installing npm packages). Perform them in the function returned from the generator. Nx won't run the returned function in the dry run mode. + +### Composing Generators + +A generator is just an async function so they can be easily composed together. This is often useful when you want to combine multiple generations. For instance, to write a generator that generates two React libraries: + +```typescript +import { + Tree, + generateFiles, + formatFiles, + installPackagesTask, +} from '@nrwl/devkit'; +import { libraryGenerator } from '@nrwl/react'; + +export default async function (tree: Tree, options: Schema) { + const libSideEffects1 = libraryGenerator(tree, { name: options.name1 }); + const libSideEffects2 = libraryGenerator(tree, { name: options.name2 }); + await performOperationsOnTheTree(tree); + return () => { + libSideEffects1(); + libSideEffects2(); + }; +} +``` + +### Testing Generators + +The Nx Devkit provides the `createTreeWithEmptyWorkspace` utility to create a tree with an empty workspace that can be used in tests. Other than that, the tests simply invoke the generator and check the changes are made in the tree. + +```typescript +import { readProjectConfiguration } from '@nrwl/devkit'; +import { createTreeWithEmptyWorkspace } from '@nrwl/devkit/testing'; +import createLib from './lib'; + +describe('lib', () => { + it('should create a lib', async () => { + const tree = createTreeWithEmptyWorkspace(); + // update tree before invoking the generator + await createLib(tree, { name: 'lib' }); + + expect(readProjectConfiguration(tree, 'lib')).toBeDefined(); + }); +}); +``` + +### Devkit Helper Functions + +Nx provides helpers several functions for writing generators: + +- `readProjectConfiguration` -- Read the project configuration stored in workspace.json and nx.json. +- `addProjectConfiguration` -- Add the project configuration stored in workspace.json and nx.json. +- `removeProjectConfiguration` -- Remove the project configuration stored in workspace.json and nx.json. +- `updateProjectConfiguration` -- Update the project configuration stored in workspace.json and nx.json. +- `readWorkspaceConfiguration` -- Read general workspace configuration such as the default project or cli settings. +- `updateWorkspaceConfiguration` -- Update general workspace configuration such as the default project or cli settings. +- `getProjects` -- Returns the list of projects. +- `generateFiles` -- Generate a folder of files based on provided templates. +- `formatFiles` -- Format all the created or updated files using Prettier. +- `readJson` -- Read a json file. +- `writeJson` -- Write a json file. +- `updateJson` -- Update a json file. +- `addDependenciesToPackageJson` -- Add dependencies and dev dependencies to package.json +- `installPackagesTask` -- Runs `npm install`/`yarn install`/`pnpm install` depending on what is used by the workspaces. +- `names` -- Util function to generate different strings based off the provided name. +- `getWorkspaceLayout` -- Tells where new libs and should be generated. +- `offestFromRoot` -- Calculates an offset from the root of the workspace, which is useful for constructing relative URLs. +- `stripIndents` -- Strips indents form a multiline string. +- `normalizePath` -- Coverts an os specific path to a unix style path. +- `joinPathFragments` -- Normalize fragments and joins them with a /. +- `toJS` -- Coverts a TypeScript file to JavaScript. Useful for generators that support both. +- `visitNotIgnoredFiles` -- Utility to act on all files in a tree that are not ignored by git. +- `applyChangesToString`-- Applies a list of changes to a string's original value. This is useful when working with ASTs + +Each of those have detailed API docs. Check the API for more information. + +It's also important to stress that those are just utility functions. You can use them but you don't have to. You can instead write your own functions that take the tree and do whatever you want to do with it. + +### Simplest Generator + +```json +{ + "cli": "nx", + "id": "CustomGenerator", + "description": "Create a custom generator", + "type": "object", + "properties": {}, + "additionalProperties": true +} +``` + +```typescript +export default async function (tree, opts) { + console.log('options', opts); +} +``` + +## Executors + +Executors act on a project commonly producing some resulting artifacts. The canonical example of an executor is one which builds a project for deployment. + +An executor consists of the following: + +- a schema that describes what options are available +- the implementation which defines what is done when performing an action on a project + +### Schema + +The executor's schema describes the inputs--what you can pass into it. + +```json +{ + "cli": "nx", + "id": "Echo", + "description": "echo given string", + "type": "object", + "properties": { + "message": { + "type": "string", + "description": "Message to echo" + }, + "upperCase": { + "type": "boolean", + "description": "Covert to all upper case", + "default": false + } + }, + "required": ["message"] +} +``` + +The schema above defines two fields: `message` and `upperCase`. The `message` field is a string, `upperCase` is a boolean. The schema support for executors and generators is identical, so see the section on generators above for more information. + +### Implementation + +The implementation function takes two arguments (the options and the target context) and returns a promise (or an async iterable) with the success property. The context params contains information about the workspace and the invoked target. + +Most of the time executors return a promise. + +```typescript +interface Schema { + message: string; + upperCase: boolean; +} + +export default async function printAllCaps( + options: Schema, + context: ExecutorContext +): Promise<{ success: true }> { + if (options.upperCase) { + console.log(options.message.toUpperCase()); + } else { + console.log(options.message); + } + return { success: true }; +} +``` + +But you can also return an async iterable that can yield several values. + +```typescript +async function wait() { + return new Promise((res) => { + setTimeout(() => res(), 1000); + }); +} + +export default async function* counter(opts: { to: number; result: boolean }) { + for (let i = 0; i < opts.to; ++i) { + console.log(i); + yield { success: false }; + await wait(); + } + yield { success: opts.result }; +} +``` + +### Composing Executors + +An executor is just a function, so you can import and invoke it directly, as follows: + +```typescript +import printAllCaps from 'print-all-caps'; + +export default async function ( + options: Schema, + context: ExecutorContext +): Promise<{ success: true }> { + // do something before + await printAllCaps({ message: 'All caps' }); + // do something after +} +``` + +This only works when you know what executor you want to invoke. Sometimes, however, you need to invoke a target. For instance, the e2e target is often configured like this: + +```json +{ + "e2e": { + "builder": "@nrwl/cypress:cypress", + "options": { + "cypressConfig": "apps/myapp-e2e/cypress.json", + "tsConfig": "apps/myapp-e2e/tsconfig.e2e.json", + "devServerTarget": "myapp:serve" + } + } +} +``` + +In this case we need to invoke the target configured in devSeverTarget. We can do it as follows: + +```typescript +async function* startDevServer( + opts: CypressExecutorOptions, + context: ExecutorContext +) { + const [project, target, configuration] = opts.devServerTarget.split(':'); + for await (const output of await runExecutor<{ + success: boolean; + baseUrl?: string; + }>( + { project, target, configuration }, + { + watch: opts.watch, + }, + context + )) { + if (!output.success && !opts.watch) + throw new Error('Could not compile application files'); + yield opts.baseUrl || (output.baseUrl as string); + } +} +``` + +The `runExecutor` utility will find the target in the configuration, find the executor, construct the options (as if you invoked it in the terminal) and invoke the executor. Note that runExecutor always returns an iterable instead of a promise. + +### Devkit Helper Functions + +- `logger` -- Wraps `console` to add some formatting. +- `getPackageManagerCommand` -- Returns commands for the package manager used in the workspace. +- `runExecutor` -- Constructs options and invokes an executor. + +### Simplest Executor + +```json +{ + "cli": "nx", + "id": "CustomExecutor", + "type": "object", + "properties": {}, + "additionalProperties": true +} +``` + +```typescript +export default async function (opts) { + console.log('options', opts); +} +``` + +## Using RxJS Observables + +The Nx devkit only uses language primitives (promises and async iterables). It doesn't use RxJS observables, but you can use them and convert them to a `Promise` or an async iterable. + +You can convert `Observables` to a `Promise` with `toPromise`. + +```typescript +import { of } from 'rxjs'; + +export default async function (opts) { + return of({ success: true }).toPromise(); +} +``` + +You can use the [`rxjs-for-await`](https://www.npmjs.com/package/rxjs-for-await) library to convert an `Observable` into an async iterable. + +```ts +import { of } from 'rxjs'; +import { eachValueFrom } from 'rxjs-for-await-async'; + +export default async function (opts) { + return eachValueFrom(of({ success: true })); +} +``` + +## Using Generators and Executors + +There are three main ways to use generators and executors: + +- Workspace generators. Learn more in [this guide](/{{framework}}/generators/workspace-generators) +- Workspace executors. Learn more in [this guide](/{{framework}}/executors/creating-custom-builders) +- Creating custom plugins. Learn more in [this guide](/{{framework}}/nx-plugin/overview) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/distributed-builds.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/distributed-builds.md new file mode 100644 index 0000000000..2788c8fd29 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/distributed-builds.md @@ -0,0 +1,14 @@ +# 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. + +The `print-affected` and `run-many` commands can be used to set up your CI to use multiple agents, while still rebuilding and retesting only what is affected. + +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). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/examples/nx-examples.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/examples/nx-examples.md new file mode 100644 index 0000000000..fc01b63367 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/examples/nx-examples.md @@ -0,0 +1,9 @@ +# 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/data-access-documents/src/data/11.4.0/shared/express-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/express-plugin.md new file mode 100644 index 0000000000..8be8ba506d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/express-plugin.md @@ -0,0 +1,128 @@ +# Express Plugin + +The Express plugin contains generators to add a new Express application to an Nx workspace. + +## Adding the Express plugin + +Adding the Express plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/express +``` + +```shell script +#npm +npm install -D @nrwl/express +``` + +> Note: You can create new workspace that has Express and React set up by doing `npx create-nx-workspace@latest --preset=react-express` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/express:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ + └── express-app/ +    ├── jest.config.js +    ├── src/ +    │   ├── app/ +    │   ├── assets/ +    │   ├── environments/ +    │   │   ├── environment.prod.ts +    │   │   └── environment.ts +    │   └── main.ts +    ├── tsconfig.app.json +    ├── tsconfig.json +    ├── tsconfig.spec.json +   └── tslint.json +``` + +The `main.ts` content should look similar to this: + +```typescript +import * as express from 'express'; + +const app = express(); + +app.get('/api', (req, res) => { + res.send({ message: 'Welcome to express-app!' }); +}); + +const port = process.env.port || 3333; +const server = app.listen(port, () => { + console.log(`Listening at http://localhost:${port}/api`); +}); +server.on('error', console.error); +``` + +#### Application Proxies + +Generating Express applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/express:application --frontendProject my-react-app +``` + +### Application commands + +When a Express application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Express application to be rebuilt automatically. +Express applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://expressjs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +##### Waiting for other builds + +Setting the `waitUntilTargets` option with an array of projects (with the following format: `"project:architect"`) will execute those commands before serving the Express application. + +#### lint + +The lint command will run linting within the scope of the Express app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Express app. + +```shell script +nx test +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-light.svg b/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-light.svg new file mode 100644 index 0000000000..8daecdac6a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-light.svg @@ -0,0 +1,3 @@ + + + diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-structure.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-structure.md new file mode 100644 index 0000000000..b631eb1a8e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/folder-structure.md @@ -0,0 +1,50 @@ +# Folder Structure + +## Files + +Every Nx workspace has a file structure like this: + +```treeview +myorg/ +├── apps/ +├── libs/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Nx makes it easy to split up your code into separate projects. Projects come in two varieties - applications and libraries. + +`/apps/` contains the application projects. These are 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 different 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 (or builders) or workspace generators. + +`/workspace.json` defines each project in your workspace and the executors that can be run on those projects. + +`/nx.json` adds extra information about projects, including manually defined dependencies and tags that can be used to restrict the ways projects are allowed to depend on each other. + +`/tsconfig.json` sets up the global typescript settings and creates aliases for each library to aid when creating typescript imports. + +## Configuration + +Many of the tools that Nx provides as plugins have a global configuration file that can be found at the root of workspace and a project-specific configuration file found at the root of each project that overrides the global settings for that project. + +For instance, `libA` has a `tsconfig.json` file that extends the global `tsconfig.json` file: + +```treeview +myorg/ +├── apps/ +├── libs/ +│ └── libA/ +│ ├── src/ +│ └── tsconfig.json +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/gatsby-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/gatsby-plugin.md new file mode 100644 index 0000000000..9e927e1c32 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/gatsby-plugin.md @@ -0,0 +1,76 @@ +# Gatsby Plugin + +The Nx Plugin for Gatsby contains executors and generators for managing Gatsby applications and libraries within an Nx workspace. It provides: + +- Scaffolding for creating, building, serving, linting, and testing Gatsby applications. +- Integration with building, serving, and exporting a Gatsby application. +- Integration with React libraries within the workspace. + +## Installing the Gatsby Plugin + +Installing the Gatsby plugin to a workspace can be done with the following: + +```shell script +yarn add -D @nrwl/gatsby +``` + +```shell script +npm install -D @nrwl/gatsby +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/gatsby:application +``` + +This creates the following app structure: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── src/ +│   │   │   ├── pages/ +│   │   │   │   ├── index.module.css +│   │   │   │   └── index.tsx +│   │   ├── jest.conf.js +│   │   ├── tsconfig.json +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.spec.json +│   │   └── .eslintrc.json +│   └── myapp-e2e/ +│   │   ├── src/ +│   │   │   ├── integrations/ +│   │   │   │   └── app.spec.ts +│   │   │   ├── fixtures/ +│   │   │   ├── plugins/ +│   │   │   └── support/ +│   │   ├── cypress.json +│   │   ├── tsconfig.e2e.json +│   │   └── .eslintrc.json +├── libs/ +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── .eslintrc.json +``` + +## See Also + +- [Using Gatsby](https://www.gatsbyjs.com/docs/quick-start/) + +## Executors / Builders + +- [build](/{{framework}}/gatsby/build) - Builds a Gatsby application +- [server](/{{framework}}/gatsby/server) - Builds and serves a Gatsby application + +## Generators + +- [application](/{{framework}}/gatsby/application) - Create a Gatsby application +- [component](/{{framework}}/gatsby/component) - Create a Gatsby component +- [page](/{{framework}}/gatsby/page) - Create a Gatsby page diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/github.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/github.png new file mode 100644 index 0000000000..d1a2a63747 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/github.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/browser-support.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/browser-support.md new file mode 100644 index 0000000000..2a94350a4b --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/browser-support.md @@ -0,0 +1,70 @@ +# 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. + +``` +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: + +``` +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 application directory to get an output of browsers and versions to support. + +```sh +$ 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: + +```sh +npx browserslist '> 0.5%, not IE 11' +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/why-monorepos.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/why-monorepos.md new file mode 100644 index 0000000000..7d97ef8765 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/guides/why-monorepos.md @@ -0,0 +1,34 @@ +## Why Monorepos? + +A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them. + +### What are the benefits of a monorepo? + +- **Shared code** - Keep your code DRY across your entire organization. Reuse validation code, UI components and types across the code base. Reuse code between the backend and the frontend. +- **Atomic changes** - Change a server API and modify the clients that consume that API in the same commit. You can change a button component in a shared library and the applications that use that component in the same commit. This saves the pain of trying to coordinate commits across multiple repositories. +- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe. +- **Single set of dependencies** - Use a single version of third party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3 year old version of a framework library or an old version of webpack. + +## Why Not Code Collocation? + +A naive implementation of a monorepo is simply code collocation - placing all the code from multiple repositories into the same repo without adequate tooling to coordinate everything. What problems arise from code collocation? + +- **Running unnecessary tests** - In order to ensure nothing was broken by a change, all tests in the entire repository need to be run - even code in projects that are unrelated to the actual change. +- **No code boundaries** - A developer from another team can change code in your project, causing bugs or inconsistencies. Or worse, another team can use code that you intended for private use - forcing you to never change that code for fear of breaking their application. +- **Inconsistent tooling** - Each project uses its own set of commands for running tests, building, serving, etc. This makes it very difficult to move from project to project. + +Tools like Lerna and Yarn Workspaces help optimize the installation of node modules, but they **do not** enable Monorepo-style development. In other words, they solve an orthogonal problem and sometimes can be used in combination with Nx. Read more on it [here](https://blog.nrwl.io/why-you-should-switch-from-lerna-to-nx-463bcaf6821). + +## Nx Can Help + +Nx provides tools to give you the benefits of a monorepo without the drawbacks of simple code collocation. + +### Scaling Your Repo + +- **Faster Command Execution** - Executors (or builders) allow for consistent commands to test, serve, build, lint, etc, each project. [Nx’s affected command]() helps run commands only on code that is affected by the current change. Nx provides local and distributed caching of executors so when someone on your team runs a command, everyone else will use their artifacts to speed up their own command executions, often bringing them down from minutes to seconds. This, in combination with support for distributed and incremental builds helps you scale your development to massive applications and repositories. + +### Scaling Your Organization + +- **Controlled Code Sharing** - You can define libraries with specific enforced APIs and put rules in place to define how those libraries can depend on each other. A CODEOWNERS file can be used to restrict who is allowed to change files in each project. +- **Consistent Code Generation** - Generators allow you to automate code creation and modification tasks. Instead of writing a 7 step guide in a readme file, you can create a generator to prompt the developer for inputs and then modify the code directly. Nrwl provides plugins which contain useful executors and generators for a lot of popular tools. Also, there is a growing number of community provided plugins. +- **Accurate Architecture Diagram** - Most architecture diagrams are wrong the moment they are written down. And every diagram becomes out of date as soon as the code changes. Since Nx understands your code, it can generate an up-to-date and accurate diagram of how projects depend on each other. And for cases where dependencies are not explicit in the code, you can manually tell Nx about project dependencies. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-build-webpack-vs-incremental.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-build-webpack-vs-incremental.png new file mode 100644 index 0000000000..9d57530a94 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-build-webpack-vs-incremental.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-builds.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-builds.md new file mode 100644 index 0000000000..bcc00dea34 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/incremental-builds.md @@ -0,0 +1,60 @@ +# Incremental Builds + +As your applications are getting bigger, one of the main ways to scale your development is to build them in an incremental fashion. +Right now, for instance, say we generate an application and a library as follows: + +```bash +nx g @nrwl/react:app myapp +nx g @nrwl/react:lib mylib +``` + +...and then import the library from the application. In this case, `mylib` isn't a buildable library. We cannot test and lint it independently, but the only way to build it is by building some application using it (in this case `myapp`). The default setup is to use Webpack, which builds "mylib" and bundles it directly into "myapp". +This provides the best dev experience for small and medium-size applications, because Webpack is optimized for this scenario. But as your application keeps growing, the dev experience degrades. + +> The **duration** of the invoked operations should be **proportional** to the **size of the change** + +## Publishable and Buildable Libraries + +Nx has **publishable libraries**. As the name suggests, such libraries are meant to be built and published to some package registry s.t. they can be consumed also from outside the Nx workspace. The executor for building a publishable library does more than just building. It makes sure the output is properly compressed and might even produce more bundles s.t. the package can be consumed in a variety of ways (e.g. also produces UMD bundles). + +``` +nx g @nrwl/react:lib mylib --publishable --importPath=@myorg/mylib +``` + +On the other hand, the executor of a **buildable library**, performs a subset of the operations compared to the publishable library's executor. That's because buildable libraries are not intended to be published and thus only produce the minimum necessary output for the incremental build scenario to work. For example, no UMD bundles or minification is being done. The main goal of the executor is to perform the build as fast as possible. + +``` +nx g @nrwl/react:lib mylib --buildable +``` + +Read more about [Publishable and Buildable Nx Libraries here.](/{{framework}}/structure/buildable-and-publishable-libraries) + +## Nx computation cache and Nx Cloud + +In an incremental build scenario, when building the app, all it's dependencies need to be built first. In our scenario above, that means we need to first run `nx build mylib` and then `nx build myapp`. As the number of libraries grows, running these commands quickly becomes unmanageable. Instead, we can run `nx build myapp --with-deps`. + +It is costly to rebuild all the buildable libraries from scratch every time you want to serve the app. That's why the Nx computation caching is so important. The caching allows us to only rebuild a small subset of the libraries, which results in much better performance. + +If we can share the cache with our teammates, we can get a much better dev experience. For instance, [this repo](https://github.com/nrwl/nx-incremental-large-repo) has a large application, where `nx serve` takes just a few seconds. + +![comparison: webpack vs incremental build](/shared/incremental-build-webpack-vs-incremental.png) + +The above chart has three different test runs: + +- **Normal build -** which visualizes using the normal Angular webpack setup executing “nx build” (blue), “nx serve” (red) and the time to rebuild/re-serve when a file change happened (yellow) + +- **Incremental build (cold) -** running all the above commands but using the Nx incremental builds but without having any kind of cache. That run takes slightly more than the normal Webpack build, which is expected. + +- **Incremental build (warm) -** running the Nx incremental build having already cached results from a previous run or from some other coworker that executed the build before. In a real world scenario, we expect always some kind of cached results either of the entire workspace or part of it. This is where the teams really get the value and speed improvements. + +## When should I use incremental builds + +We're continously improving the speed of incremental builds. However as of now, incremental builds become really benefitial in **really large repositories**. + +Also, using incremental builds only really makes sense when using the distributed Nx caching with Nx Cloud. Check out [nx.app](https://nx.app) for more information on how to setup distributed caching. + +## Setup an incremental build + +- [Setup an incremental build for an Angular app](/angular/ci/setup-incremental-builds-angular) +- _Setup an incremental build for a React app (soon)_ +- _Setup an incremental build for a Node app (soon)_ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-logo.png new file mode 100644 index 0000000000..ac0c0f5e44 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-plugin.md new file mode 100644 index 0000000000..a85dc68adb --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/jest-plugin.md @@ -0,0 +1,110 @@ +# Jest Plugin + +![Jest logo](/shared/jest-logo.png) + +[Jest](https://jestjs.io/) is an open source test runner created by Facebook. It is used within Facebook internally as well as many other enterprise and open source projects including Nx itself! + +## Reasons for Using Jest + +- Jest was built with monorepos in mind and is able to isolate the important parts of a monorepo to test. +- Jest has a great built-in reporter for printing out results of tests. +- Jest has an immersive watch mode which provides near instant feedback when developing tests. +- Jest provides the ability to use Snapshot Testing to validate features. +- And more... + +## How to use Jest + +By default, Nx will use Jest when creating applications and libraries. + +```treeview +/ +├── apps/ +│   ├── frontend/ +│   │   ├── src/ +│   │   ├── browserslist +│   │   ├── jest.config.js # <== jest config +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   └── tsconfig.spec.json +│   └── frontend-e2e/ +├── libs/ +├── tools/ +├── nx.json +├── package.json +├── README.md +├── workspace.json +└── tsconfig.json +``` + +Depending on the project you are creating, Nx can support other test runners in addition to Jest. You can configure the test runner you use by passing `--unit-test-runner=jest` when creating applications or libraries. + +### Running Tests + +```bash +nx test frontend +``` + +### Snapshot Testing + +Jest has support for **Snapshot Testing**, a tool which simplifies validating data did not change. Check out the [official Jest Documentation on Snapshot Testing](https://jestjs.io/docs/en/snapshot-testing). + +#### Writing Tests Using Snapshot Testing + +To write a test which uses **Snapshot Testing**, use the `toMatchSnapshot()` matcher. + +```typescript +describe('Home Page', () => { + it('should have a header', () => { + const header = renderHeader(); + expect(header).toMatchSnapshot(); + }); +}); +``` + +The snapshot will be generated the first time the test is run. If the contents of that snapshot change, the test will fail indicating unexpected changes to the snapshot. Below is an example of the test results if the hamburger icon disappears unintentionally. + +```bash +Home Page > should have a header + expect(value).toMatchSnapshot() + Received value does not match stored snapshot "Home Page should have a header 1". + - Snapshot ++ Received +
+

+- +- hamburger +- + Example +

+
+``` + +> Note: These snapshot files should be checked in with your code. + +#### Updating Snapshots + +When intentionally changing the contents of a snapshot, you can run tests with the `--updateSnapshot` flag to update failing snapshots instead of failing the test. + +```bash +nx test libname --updateSnapshot +``` + +> Make sure no **unintentional** snapshots are failing **BEFORE** updating failing snapshots. + +### Watching for Changes + +If you are a developer making changes locally to a library, start jest's interactive watch mode to run the library's tests related to uncommitted changes and then rerun tests whenever files are changed. + +```bash +nx test libname --watch +``` + +#### Debugging Failing Tests + +To debug failing tests using Chrome Devtools or an IDE you can run the test command through node's `--inspect-brk` flag. + +```bash +node --inspect-brk ./node_modules/nx/bin/nx test libname +``` + +Now, you can visit [chrome://inspect](chrome://inspect) in Chrome and inspect the target to attach to the node process. You can now use Chrome Devtools to step through your code line by line and debug the cause of the failing tests. Visit the official [Jest documentation](https://jestjs.io/docs/en/troubleshooting#tests-are-failing-and-you-don-t-know-why) to find out more. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/adding-to-monorepo.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/adding-to-monorepo.md new file mode 100644 index 0000000000..47a08a4a5d --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/adding-to-monorepo.md @@ -0,0 +1,104 @@ +# Next Steps After Adding Nx to Monorepo + +If you have a monorepo that is powered by Lerna, Yarn, PNPM, or NPM, you can transform it into an Nx workspace by +running this command: `npx add-nx-to-monorepo`. + +See it in action (3-minute video): + + + +`npx add-nx-to-monorepo` will do the following: + +1. Add Nx to your package.json +2. Create `workspace.json` and `nx.json` listing all the projects in the workspace +3. Set up a `tsconfig` file mapping all projects in there +4. Set up Nx Cloud (if you say "yes") + +## What You Get Right Away + +After you run the command above, you can any npm script using Nx. For instance, if `myproj` has a `build` script, you can invoke it using `npx nx build myproj`. If you pass any flags, they will be forwarded to the underlying script. + +### Caching Works + +Nx supports computation caching. If it has seen the computation you are trying to perform, it's going extract the result from its cache instead of running it. An easy way to see it in action is to run the same command +twice: `npx nx build myproj` and then again `npx nx build myproj`. In addition to restoring all the files, Nx will +replay the terminal output as well, so you don't lose any information when running a cached command. + +### Distributed Caching Works + +If you said "yes" to Nx Cloud, you can now clone the repo on a different machine (e.g., CI) and run the same command against the same commit and the results will be retrieved from cache. Never compute the same thing twice in your org or CI. + +### Affected Works + +Nx will automatically analyze your workspace to know what projects are affected by your commit. Simply run: `npx nx affected --target=test --base=main` to see it in action. Often, Nx is able to do a better job detecting +affected than other tools because it looks not just at the changed files but also at the nature of the changes. + +### Workspace Visualization + +Run `npx nx dep-graph` to see a visualization of your workspace. `npx nx affected:dep-graph` will show what is affected +by your commit. + + + +### Github Integration Works + +If you said "yes" to Nx Cloud, you can enable Nx Cloud - Github integration to get a much better overview of what +happens in your PRs. + +![Nx Console screenshot](/shared/github.png) + +### VS Code Plugin Works + +![Nx Console screenshot](/shared/nx-console-screenshot.png) + +## Next Steps + +All this works without your having to change your repo in any way. Whatever setup you have still works the same way but +faster and with better dev ergonomics. But Nx enables much more than that. + +Nx is like a VS Code of build tools. It has a very powerful core but it's really the plugins and extra capabilities that +really transform how you develop. + +Nx has first class support for React, Next.js, Gatsby, React Native, Angular, Node, NestJS, Jest, Cypress, Storybook and +many more. All the plugins are designed to work together and create a cohesive and pleasant to use dev environment. + +In addition, Nx makes a lot of things much easier, like building large apps incrementally, distributing CI (no point in doing caching unless you can do that), enforcing best practices, building design systems. + +If you want to explore what it feels like to develop with Nx, check out: + +- [nx.dev/react](https://nx.dev/react) +- [nx.dev/angular](https://nx.dev/angular) +- [nx.dev/node](https://nx.dev/node) + +## Troubleshooting + +The `add-nx-to-monorepo` command will do its best to figure out what projects you have in the repo, but you can always update the list yourself. + +For instance, you can add/remove/update projects in `workspace.json`. + +```json +{ + "version": 2, + "projects": { + "one": { "root": "packages/one", "type": "library" }, + "two": { "root": "packages/two", "type": "library" } + } +} +``` + +Nx will a root tsconfig with something like this: + +```json +{ + "compilerOptions": { + "paths": { + "one": ["packages/one/index"], + "one/*": ["packages/one/*"], + "two": ["packages/two/index"], + "two/*": ["packages/two/*"] + } + } +} +``` + +This tsconfig isn't used for building or testing. It's only used to teach Nx how to resolve imports, so Nx can do its import source code analysis. If the path mappings are deduced incorrectly, feel free to chang them. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/overview.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/overview.md new file mode 100644 index 0000000000..bcc5d49851 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/overview.md @@ -0,0 +1,201 @@ +# Migrating existing code bases + +## What you’ll accomplish + +Migrating into an Nx workspace can seem intimidating. While every codebase is unique, we can offer recommendations for how to proceed based on the Nrwl team’s years of experience. The key to success is an incremental approach. You don’t need to migrate your entire codebase at once. Find a good target for migration, move it into your Nx workspace, get it working and stable, and go from there. + +This document will introduce you to the Nx workspace, help you get one created, and point you to some particular configuration that you may need for your codebase. + +## Create a workspace + +To get started, you’ll need an Nx workspace. While Nx offers several preset configurations for your workspace, we recommend starting migration with an `empty` workspace. This will allow you to have finer control over the configuration and creation of the applications and libraries in your workspace. + +To create an empty workspace: + +```bash +npx create-nx-workspace@latest +``` + +Select `empty` when prompted: + +```bash +? What to create in the new workspace (Use arrow keys) +❯ empty [an empty workspace] +``` + +## Exploring your workspace + +Take a tour of your [Nx workspace](/{{framework}}/getting-started/folder-structure). There are some important areas to know about as you migrate. + +### apps + +The `apps` directory is the place where your top-level applications will be stored. You should always begin your migration journey by adding an application. + +For Angular applications: + +```bash +npm install --save-dev @nrwl/angular +``` + +and + +```bash +nx generate @nrwl/angular:application my-application +``` + +For React applications: + +```bash +npm install --save-dev @nrwl/react +``` + +and + +```bash +nx generate @nrwl/react:application my-application +``` + +There are a lot of options when creating your application. If you want to follow Nx recommendations, you can accept the defaults. If you have a well-established codebase, you can configure those options at the time of application generation. You can find documentation for these options for the different frameworks here: + +- [Angular](/{{framework}}/angular/application) +- [React](/{{framework}}/react/application) + +You may also find it useful to use the [Nx Console](/{{framework}}/getting-started/console) in Visual Studio Code. This will give you a visual way to generate your application with all of the options laid out in front of you. + +### Configuration files + +Your workspace contains different configuration files for the tools you’ll need to develop, such as linters, bundlers, and builders. There are two sources of configuration files for your workspace: at the root of the workspace and at the root of your application. The configuration files at the root of your application extend the configuration files found at the root of your workspace. If you need to make global adjustments to these configurations, you should do so at the root of the workspace. If you have multiple applications that need different configurations, you should manage this using the configuration files in the root of each application. + +In general, you should not replace the configuration files provided for you. You should add to or modify the configurations that are there. This will help ensure that your configuration files are set up for Nx to work at its best. + +### Nx Configuration Files + +In addition to configuration files for external libraries, your Nx workspace will have configuration files for Nx itself. This will be `angular.json` for workspaces using the Angular CLI and `workspace.json` for workspaces using the Nx CLI. This file will define all of the individual projects in your workspace (of which your application is one) and the tasks available for them. + +For example, your generated application should have four [tasks available]({{framework}}/executors/using-builders) for it: `build`, `serve`, `lint`, and `test`. Each of these comes with its own configuration. If you find you need to adjust the configuration of a task for your codebase, this is the place to begin looking. + +These workspace configuration files can seem a little long and intimidating. The Nx Console can help you navigate it more easily with its Workspace JSON panel. By clicking on a project in your workspace, it will navigate you to the right place in the workspace file to begin making edits. + +Additionally, there is an `nx.json` file that contains metadata about your projects. [This metadata includes tags]({{framework}}/structure/monorepo-tags) that can help you impose constraints on your applications and library dependencies. + +## Migrating your code + +There are two major steps to migrating your application: migrating your dependencies and migrating your code. + +### Dependencies + +If you’re already using npm for package management, this is as easy as copying your dependencies from your old `package.json` file to your workspace’s `package.json`. Make sure you don’t add any duplicate dependencies during this step. + +If you’re using other package managers such as Bower, you’ll need to take an intermediary step of moving your dependencies from there to NPM. For Bower, [migration information is available](https://bower.io/blog/2017/how-to-migrate-away-from-bower/) + +### Code + +If your code is all in a single app, you can copy it into the application’s folder. Configuration files go in the root of your application, and application code goes into the `src/app` folder. Assets such as images, icons, and fonts can go into the `src/assets` directory. An `index.html` is provided for you in `src`. You should add anything else you may need such as external fonts or icons from a CDN. `src/main.ts` will bootstrap your application. You may need to modify this file or modify your application file names to bootstrap your app. + +## Running tasks + +Now that your code is present, it’s time to tackle building and testing it. + +Local build and serve +Each generated application has a build process defined by Nx. This uses the Angular CLI for Angular, and webpack is used for all other projects. See if this build process works out of the box for you by running + +```bash +nx serve my-application +``` + +If this doesn’t work for you, you may need to add or modify some configuration on the `build` task in your workspace configuration file. + +[Learn more about local serving](/{{framework}}/cli/serve) + +### Unit tests + +Each application will have a unit test process defined by your choices (Jest or Karma) during the creation of the application. To run tests for your application: + +```bash +nx test my-application +``` + +It is recommended that unit tests live next to the code they exercise and code scaffolded by Nx will follow this pattern. If your unit tests currently live in a separate directory, you may need to modify your test configuration or move your test files. + +Testing configuration files can be found in the root of your application as well as the workspace configuration file. + +[Learn more about unit testing](/{{framework}}/cli/test) + +### End to End Tests + +Each application will have an e2e configuration created as a separate application, appended with `-e2e`. In our example, you’ll see `my-application-e2e`. This `e2e` task uses the test runner you chose during generation, Protractor or Cypress. Your application’s e2e tests should be migrated to this directory. There will be an e2e test scaffolded for you to make sure everything works before you start adding your own. To run the e2e tests: + +```bash +nx e2e my-application-e2e +``` + +All of the configuration for your e2e tests should be in this directory. + +[Learn more about end-to-end testing](/{{framework}}/cli/e2e) + +### Linting + +Nx uses either tslint or eslint for linting, based on your application’s configuration. Nx also has its own lint process to make sure your Nx configuration is valid. + +To run the `lint` task for your workspace + +```bash +nx lint +``` + +To run the `lint` task for a particular application: + +```bash +nx lint my-application +``` + +Global configuration files for linting will be at the root of your workspace. Each application and library will extend those configuration files. Global configuration changes should be made in the root, while application-or-library-specific changes should occur in the application or library configuration files. + +[Learn more about linting](/{{framework}}/cli/lint) + +### Formatting + +Nx uses Prettier to ensure standard formatting across your codebase. Prettier configuration files are located in the root of the workspace. To format your workspace run: + +```bash +nx format:write +``` + +[Learn more about formatting](/{{framework}}/cli/format-write) + +### Adding tasks + +Nx offers built-in tasks for the most common needs: `serve`, `build`, `test`, `e2e`, and `lint`. You likely have additional tasks that are needed to manage or deploy your codebase. These tasks might include deployment, i18n workflows, or uploading assets to CDNs. These tasks can be set up as scripts that you run manually with node, ts-node, or npm scripts. You can migrate those tasks over as-is, to begin with. + +You should consider implementing them as Nx tasks which should be a quick transition with the `run-commands` builder. [The `run-commands` builder](/{{framework}}/executors/run-commands-builder) will allow you to run any custom commands you need as an Nx task. By implementing these commands in an Nx task, they are able to take advantage of the dependency graph in Nx and only run when necessary. They are also able to be cached and only be re-run when necessary. + +Your use-case may also be covered by one of our community plugins. Plugin authors are able to extend the functionality of Nx through our plugin API. + +[Learn more about the `run-commands` builder](/{{framework}}/workspace/run-commands-executor) + +[Learn more about caching](/{{framework}}/core-concepts/computation-caching) + +[Learn more about community plugins](/nx-community) + +## Migrating libraries + +If your code is divided into libraries, you should also generate libraries for your code to migrate into: + +For Angular libraries: + +```bash +nx generate @nrwl/angular:library +``` + +For React libraries: + +```bash +nx generate @nrwl/react:library +``` + +It’s important to remember: don’t just drop your code anywhere! Always generate an app or a library for that code before migration. Without the project configuration, you’ll miss out on key functionalities of Nx provided by the dependency graph generation and affected code detection. + +Establishing code boundaries +If you’re consolidating multiple repositories or libraries into a single Nx workspace, you may have concerns about code boundaries. Previously, you may have had well-established boundaries by separating code into different repositories or having a public API for a library. Nx features a tagging system that allows you to enforce these code boundaries in a granular way. Each project can be tagged, and you can constrain dependencies based on these tags. + +[Learn more about tags and dependency constraints](/{{framework}}/structure/monorepo-tags) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/preserving-git-histories.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/preserving-git-histories.md new file mode 100644 index 0000000000..5ff6876083 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/migration/preserving-git-histories.md @@ -0,0 +1,39 @@ +# Preserving Git Histories When Migrating Other Projects to Your Nx Workspace + +The nature of a mono-repo is to swallow up stand-alone projects as your organization buys into the benefits of a mono-repo workflow. + +As your mono-repo consumes other projects though, it's important to ensure that git history for those projects is preserved inside of our Nx Workspace. + +Git has some helpful tools for this, and we'll walk through some of the common pitfalls and gotchas of this task! + +## Merging In a Standalone Project + +To merge in another project, we'll essentially use the standard `git merge` command, but with a few lesser known options/caveats. + +To start we'll add a remote repository url for where the standalone app is located: + +```bash +git remote add my-stand-alone-app +``` + +Assuming that our main branch on this repo is called 'master', then we'll run + +```bash +git merge my-stand-alone-app/master --allow-unrelated-histories +``` + +Note that without the `--allow-unrelated-histories` option, the command would fail with the message: `fatal: refusing to merge unrelated histories`. + +## Merge Conflicts + +At this point, it is very likely that you'll have merge conflicts in your root files. + +For your `package-lock.json` or `yarn.lock`, it's likely best to remove those entirely and allow a new lock file to be generated by installing when the merge is complete. + +For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. + +Note that for these files, the file-history of the stand-alone project will be not be present after merging. You would see all changes from resolving conflicts in the single merge commit, and any further back would simply be the file history of your workspace. + +## Using `git mv` + +Especially if your stand-alone project was not an Nx workspace, it's likely that your migration work will also entail moving around directories to match a typical Nx Workspace structure. You can find more information in the [Overview](/{{framework}}/migration/overview) page, but when migrating an existing project, you'll want to ensure that you use [`git mv`](https://git-scm.com/docs/git-mv) when moving a file or directory to ensure that file history from the old standalone repo is not lost! diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-azure.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-azure.md new file mode 100644 index 0000000000..464c20fa73 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-azure.md @@ -0,0 +1,283 @@ +# Distributed CI Using Azure Pipelines + +Nx is a set of extensible dev tools for monorepos. 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 +- ... + +But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. + +## Example Workspace + +[This repo](https://github.com/nrwl/nx-azure-build) is an example Nx Workspace. It has two applications. Each app has 15 libraries, each of which consists of 30 components. The two applications also share code. + +If you run `nx dep-graph`, you will see somethign like this: + +![dependency-graph](/shared/ci-graph.png) + +### CI Provider + +This example will use Azure Pipelines, but a very similar setup will work with CircleCI, Jenkins, GitLab, etc.. + +### **To see CI runs click [here](https://dev.azure.com/nrwlio/nx-azure-ci/_build?definitionId=6&_a=summary).** + +## Baseline + +Most projects that don't use Nx end up building, testing, and linting every single library and application in the repository. The easiest way to implement it with Nx is to do something like this: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx run-many --target=test --all + - script: yarn nx run-many --target=lint --all + - script: yarn nx run-many --target=build --all --prod +``` + +This will retest, relint, rebuild every project. Doing this for this repository takes about 45 minutes (note that most enterprise monorepos are significantly larger, so in those cases we are talking about many hours.) + +The easiest way to make your CI faster is to do less work, and Nx is great at that. + +## Building Only What is Affected + +Nx knows what is affected by your PR, so it doesn't have to test/build/lint everything. Say the PR only touches `ng-lib9`. If you run `nx affected:dep-graph`, you will see something like this: + +![dependency-graph one library affected](/shared/ci-graph-one-affected.png) + +If you update `azure-pipelines.yml` to use `nx affected` instead of `nx run-many`: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx affected --target=test --base=origin/master + - script: yarn nx affected --target=lint --base=origin/master + - script: yarn nx affected --target=build --base=origin/master --prod +``` + +the CI time will go down from 45 minutes to 8 minutes. + +This is a good result. It helps to lower the average CI time, but doesn't help with the worst case scenario. Some PR are going to affect a large portion of the repo. + +![dependency-graph everything affected](/shared/ci-graph-everything-affected.png) + +You could make it faster by running the commands in parallel: + +```yaml +jobs: + - job: ci + timeoutInMinutes: 120 + pool: + vmImage: 'ubuntu-latest' + variables: + IS_PR: $[ eq(variables['Build.Reason'], 'PullRequest') ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: yarn nx affected --target=test --base=origin/master --parallel + - script: yarn nx affected --target=lint --base=origin/master --parallel + - script: yarn nx affected --target=build --base=origin/master --prod --parallel +``` + +This helps but it still has a ceiling. At some point, this won't be enough. A single agent is simply insufficent. You need to distribute CI across a grid of machines. + +## Distributed CI + +To distribute you need to split your job into multiple jobs. + +``` + + / lint1 +Prepare Distributed Tasks - lint2 + - lint3 + - test1 + .... + \ build3 + +``` + +### Distributed Setup + +The `distributed_tasks` job figures out what is affected and what needs to run on what agent. + +```yaml +jobs: + - job: distributed_tasks + pool: + vmImage: 'ubuntu-latest' + variables: + IS_PR: $[ eq(variables['Build.Reason'], 'PullRequest') ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - powershell: echo "##vso[task.setvariable variable=COMMANDS;isOutput=true]$(node ./tools/scripts/calculate-commands.js $(IS_PR))" + name: setCommands + - script: echo $(setCommands.COMMANDS) + name: echoCommands +``` + +Where `calculate-commands.js` looks like this: + +```javascript +const execSync = require('child_process').execSync; +const isMaster = process.argv[2] === 'False'; +const baseSha = isMaster ? 'origin/master~1' : 'origin/master'; + +// prints an object with keys {lint1: [...], lint2: [...], lint3: [...], test1: [...], .... build3: [...]} +console.log( + JSON.stringify({ + ...commands('lint'), + ...commands('test'), + ...commands('build'), + }) +); + +function commands(target) { + const array = JSON.parse( + execSync(`npx nx print-affected --base=${baseSha} --target=${target}`) + .toString() + .trim() + ).tasks.map((t) => t.target.project); + + array.sort(() => 0.5 - Math.random()); + const third = Math.floor(array.length / 3); + const a1 = array.slice(0, third); + const a2 = array.slice(third, third * 2); + const a3 = array.slice(third * 2); + return { + [target + '1']: a1, + [target + '2']: a2, + [target + '3']: a3, + }; +} +``` + +Let's step through it: + +The following defines the base sha Nx uses to execute affected commands. + +```javascript +const isMaster = process.argv[2] === 'False'; +const baseSha = isMaster ? 'origin/master~1' : 'origin/master'; +``` + +If it is a PR, Nx sees what has changed compared to `origin/master`. If it's master, Nx sees what has changed compared to the previous commit (this can be made more robust by remembering the last successful master run, which can be done by labeling the commit). + +The following prints information about affected project that have the needed target. `print-affected` doesn't run any targets, just prints information about them. + +```javascript +execSync(`npx nx print-affected --base=${baseSha} --target=${target}`) + .toString() + .trim(); +``` + +The rest of the `commands` splits the list of projects into three groups or bins. + +### Other Jobs + +Other jobs use the information created by `distributed_tasks` to execute the needed tasks. + +```yaml +- job: lint1 + dependsOn: distributed_tasks # this tells lin1 to wait for distributed_tasks to complete + condition: | + and( + succeeded(), + not(contains( + dependencies.distributed_tasks.outputs['setCommands.COMMANDS'], + '"lint1":[]' + )) + ) + pool: + vmImage: 'ubuntu-latest' + variables: + COMMANDS: $[ dependencies.distributed_tasks.outputs['setCommands.COMMANDS'] ] + steps: + - template: .azure-pipelines/steps/install-node-modules.yml + - script: node ./tools/scripts/run-many.js '$(COMMANDS)' lint1 lint +``` + +where `run-many.js`: + +```javascript +const execSync = require('child_process').execSync; + +const commands = JSON.parse(process.argv[2]); +const projects = commands[process.argv[3]]; +const target = process.argv[4]; +execSync( + `npx nx run-many --target=${target} --projects=${projects.join( + ',' + )} --parallel`, + { + stdio: [0, 1, 2], + } +); +``` + +### Artifacts + +This example doesn't do anything with the artifacts created by the build, but often you will need to upload/deploy them. There are several ways to handle it. + +1. You can create a job per application and then copy the output to the staging area, and then once tests complete unstage the files in a separate job and then deploy them. +2. You can use the outputs property from running `npx nx print-affected --target=build` to stash and unstash files without having a job per app. + +```json +{ + "tasks": [ + { + "id": "react-app:build", + "overrides": {}, + "target": { + "project": "react-app", + "target": "build" + }, + "command": "npm run nx -- build react-app", + "outputs": [ + "dist/apps/react-app" + ] + }, + { + "id": "ng-app:build", + "overrides": {}, + "target": { + "project": "ng-app", + "target": "build" + }, + "command": "npm run nx -- build ng-app", + "outputs": [ + "dist/apps/ng-app" + ] + } + ], + "dependencyGraph": { + ... + } +} +``` + +### Improvements + +With these changes, rebuild/retesting/relinting everything takes only 7 minutes. The average CI time is even faster. The best part of this is that you can add more agents to your pool when needed, so the worst-case scenario CI time will always be under 15 minutes regardless of how big the repo is. + +### Can We Do Better? + +This example uses a fixed agent graph. This setup works without any problems for all CI providers. It also scales well for repo of almost any size. So before doing anything more sophisticated, I'd try this approach. Some CI providers (e.g., Jenkins) allow scaling the number of agents dynamically. The `print-affected` and `run-many` commands can be used to implement those setups as well. + +## Summary + +1. Rebuilding/retesting/relinting everyting on every code change doesn't scale. **In this example it takes 45 minutes.** +2. Nx lets you rebuild only what is affected, which drastically improves the average CI time, but it doesn't address the worst-case scenario. +3. Nx helps you run multiple targets in parallel on the same machine. +4. Nx provides `print-affected` and `run-many` which make implemented distributed CI simple. **In this example the time went down from 45 minutes to only 7** diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-jenkins.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-jenkins.md new file mode 100644 index 0000000000..3b31d0fc19 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-ci-jenkins.md @@ -0,0 +1,287 @@ +# Distributed CI Using Jenkins + +Nx is a set of extensible dev tools for monorepos. 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 +- ... + +But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. + +## Example Workspace + +[This repo](https://github.com/nrwl/nx-jenkins-build) is an example Nx Workspace. It has two applications. Each app has 15 libraries, each of which consists of 30 components. The two applications also share code. + +If you run `nx dep-graph`, you will see somethign like this: + +![dependency-graph](/shared/ci-graph.png) + +### CI Provider + +This example will use Jenkins. An [azure pipelines example](https://github.com/nrwl/nx-azure-build) is here, but it should not be too hard to implement the same setup on other platforms. + +## Baseline + +Most projects that don't use Nx end up building, testing, and linting every single library and application in the repository. The easiest way to implement it with Nx is to do something like this: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx run-many --target=test --all' + } + + stage("Lint") { + sh 'yarn nx run-many --target=lint --all' + } + + stage("Build") { + sh 'yarn nx run-many --target=build --all --prod' + } + } + } +} +``` + +This will retest, relint, rebuild every project. Doing this for this repository takes about 45 minutes (note that most enterprise monorepos are significantly larger, so in those cases we are talking about many hours.) + +The easiest way to make your CI faster is to do less work, and Nx is great at that. + +## Building Only What is Affected + +Nx knows what is affected by your PR, so it doesn't have to test/build/lint everything. Say the PR only touches `ng-lib9`. If you run `nx affected:dep-graph`, you will see something like this: + +![dependency-graph one library affected](/shared/ci-graph-one-affected.png) + +If you update `azure-pipelines.yml` to use `nx affected` instead of `nx run-many`: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx affected --target=test --base=origin/master' + } + + stage("Lint") { + sh 'yarn nx affected --target=lint --base=origin/master' + } + + stage("Build") { + sh 'yarn nx affected --target=build --base=origin/master --prod' + } + } + } +} +``` + +the CI time will go down from 45 minutes to 8 minutes. + +This is a good result. It helps to lower the average CI time, but doesn't help with the worst case scenario. Some PR are going to affect a large portion of the repo. + +![dependency-graph everything affected](/shared/ci-graph-everything-affected.png) + +You could make it faster by running the commands in parallel: + +```groovy +node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config') { + stage("Prepare") { + checkout scm + sh 'yarn install' + } + + stage("Test") { + sh 'yarn nx affected --target=test --base=origin/master --parallel' + } + + stage("Lint") { + sh 'yarn nx affected --target=lint --base=origin/master --parallel' + } + + stage("Build") { + sh 'yarn nx affected --target=build --base=origin/master --prod --parallel' + } + } + } +} +``` + +This helps but it still has a ceiling. At some point, this won't be enough. A single agent is simply insufficent. You need to distribute CI across a grid of machines. + +## Distributed CI + +To distribute you need to split your job into multiple jobs. + +``` + + / lint1 +Prepare Distributed Tasks - lint2 + - lint3 + - test1 + .... + \ build3 + +``` + +### Distributed Setup + +```groovy +def distributedTasks = [:] + +stage("Building Distributed Tasks") { + jsTask { + checkout scm + sh 'yarn install' + + distributedTasks << distributed('test', 3) + distributedTasks << distributed('lint', 3) + distributedTasks << distributed('build', 3) + } +} + +stage("Run Distributed Tasks") { + parallel distributedTasks +} + +def jsTask(Closure cl) { + node { + withEnv(["HOME=${workspace}"]) { + docker.image('node:latest').inside('--tmpfs /.config', cl) + } + } +} + +def distributed(String target, int bins) { + def jobs = splitJobs(target, bins) + def tasks = [:] + + jobs.eachWithIndex { jobRun, i -> + def list = jobRun.join(',') + def title = "${target} - ${i}" + + tasks[title] = { + jsTask { + stage(title) { + checkout scm + sh 'yarn install' + sh "npx nx run-many --target=${target} --projects=${list} --parallel" + } + } + } + } + + return tasks +} + +def splitJobs(String target, int bins) { + def String baseSha = env.CHANGE_ID ? 'origin/master' : 'origin/master~1' + def String raw + raw = sh(script: "npx nx print-affected --base=${baseSha} --target=${target}", returnStdout: true) + def data = readJSON(text: raw) + + def tasks = data['tasks'].collect { it['target']['project'] } + + if (tasks.size() == 0) { + return tasks + } + + // this has to happen because Math.ceil is not allowed by jenkins sandbox (╯°□°）╯︵ ┻━┻ + def c = sh(script: "echo \$(( ${tasks.size()} / ${bins} ))", returnStdout: true).toInteger() + def split = tasks.collate(c) + + return split +} + +``` + +Let's step through it: + +To run jobs in parallel with jenkins, we need to construct a map of `string -> closure` where `closure` contains the code we want to be running +in parallel. The goal of the `distributed` function is to build a compatible map. It starts by figuring out what jobs need to be run, and +splitting them into bins via `splitJobs`. + +Looking at `splitJobs`, the following defines the base sha Nx uses to execute affected commands. + +```groovy + def String baseSha = env.CHANGE_ID ? 'origin/master' : 'origin/master~1' +``` + +Jenkins will only have a CHANGE_ID if it is a PR. + +If it is a PR, Nx sees what has changed compared to `origin/master`. If it's master, Nx sees what has changed compared to the previous commit (this can be made more robust by remembering the last successful master run, which can be done by labeling the commit). + +The following prints information about affected project that have the needed target. `print-affected` doesn't run any targets, just prints information about them. + +```groovy +def String raw +jsTask { raw = sh(script: "npx nx print-affected --base=${baseSha} --target=${target}", returnStdout: true) } +def data = readJSON(text: raw) +``` + +We split the jobs into bins with `collate`. + +Once we have our lists of jobs, we can go back to the `distributed` method. We loop over the list of split jobs for our target, +and construct the map that jenkins requires to parallelize our jobs. + +```groovy +def tasks = [:] + +jobs.eachWithIndex { jobRun, i -> +jsTask { echo 'loop' } + +def list = jobRun.join(',') +def title = "${target} - ${i}" + +tasks[title] = { + jsTask { + stage(title) { + sh "npx nx run-many --target=${target} --projects=${list} --parallel" + } + } +} +} +``` + +finally, we merge each map of target jobs into a big map, and pass that to `parallel`. + +```groovy +stage("Building Distributed Tasks") { + jsTask { + checkout scm + sh 'yarn install' + + distributedTasks << distributed('test', 3) + distributedTasks << distributed('lint', 3) + distributedTasks << distributed('build', 3) + } +} + +``` + +### Improvements + +With these changes, rebuild/retesting/relinting everything takes only 7 minutes. The average CI time is even faster. The best part of this is that you can add more agents to your pool when needed, so the worst-case scenario CI time will always be under 15 minutes regardless of how big the repo is. + +## Summary + +1. Rebuilding/retesting/relinting everyting on every code change doesn't scale. **In this example it takes 45 minutes.** +2. Nx lets you rebuild only what is affected, which drastically improves the average CI time, but it doesn't address the worst-case scenario. +3. Nx helps you run multiple targets in parallel on the same machine. +4. Nx provides `print-affected` and `run-many` which make implemented distributed CI simple. **In this example the time went down from 45 minutes to only 7** diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-nx-enterprise.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-nx-enterprise.md new file mode 100644 index 0000000000..7cb1fb7114 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-nx-enterprise.md @@ -0,0 +1,198 @@ +# Using Nx at Enterprises + +Nx is a great tool for companies of all sizes. These days even small products have several microservies and several frontends (say desktop and mobile) which are often built by distributed teams. Being able to do this type of development holistically, using modern tools, is as important for a startup as it is for a well-established organization. + +Some things, however, are much more important for large companies: + +- Code organization & naming conventions +- Code ownership +- Enforcing best practices +- Developer workflow +- Deployment flexibility + +> Everything below are just recommendations. Every large organization has unique needs, so treat this document as a starting point not the definite list of what you must and must not do. + +## Code Organization & Naming Conventions + +### Apps and Libs + +- Apps configure dependency injection and wire up libraries. They should not contain any components, services, or business logic. +- Libs contain services, components, utilities, etc.. They have well-defined public API. + +A typical Nx workspace has many more libs than apps, so pay especially careful attention to the organization of the libs directory. + +### Scope (Where a library lives, who owns it) + +It's a good convention to put applications-specific libraries into the directory matching the application name. This provides enough organization for small to mid-size applications. + +```treeview +happynrwl/ +├── apps/ +│ ├── happynrwlapp/ +│ ├── happynrwlapp-e2e/ +│ ├── adminapp/ +│ └── adminapp-e2e/ +├── libs/ +│ ├── happynrwlapp/ +│ │ ├── feature-main/ +│ │ ├── ui-table/ +│ │ └── utils-testing/ +│ ├── adminapp/ +│ │ ├── feature-main/ +│ │ ├── feature-login/ +│ │ ├── ui/ +│ │ └── utils-testing/ +│ └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +For larger projects, it is a good idea to group libraries into application sections. + +```treeview +happynrwl/ +├── apps/ +├── libs/ +│ ├── happynrwlapp/ +│ │ ├── registration/ +│ │ │ ├── feature-main/ +│ │ │ ├── feature-login/ +│ │ │ ├── ui-form/ +│ │ │ └── utils-testing/ +│ │ ├── search/ +│ │ │ ├── feature-results/ +│ │ │ └── utils-testing/ +│ │ └── shared/ +│ │ └── ui/ +│ ├── adminapp/ +| └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Here we have: + +- `happynrwlapp/registration/feature-main`--a scoped library used in one place +- `happynrwlapp/shared/ui`--a shared library used in a single application +- `shared/ui`--a shared library used across applications + +**Portal** + +Many enterprise applications are portals: slim shells loading different modules at runtime. If this is what you are building, the following might be a better starting point: + +```treeview +happynrwl/ +├── apps/ +│ ├── happynrwlapp/ +│ ├── happynrwlapp-e2e/ +├── libs/ +│ ├── shell/ +│ │ └── feature-main +│ ├── registration/ +│ │ ├── feature-main/ +│ │ ├── feature-login/ +│ │ ├── ui-form/ +│ │ └── utils-testing/ +│ ├── search/ +│ │ ├── feature-results/ +│ │ └── utils-testing/ +│ └── shared/ +│ ├── ui/ +│ └── utils-testing/ +├── tools/ +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +### Type (What is in the library) + +With Nx, we can partition our code into small libraries with well-defined public API. So we can categorize our libraries based on what they contain. + +**These are some common library types:** + +- Utility libraries contain utilities and services. +- Data-access can contain NgRx-related code. +- Component libraries should contain presentational components and directives. +- Feature libraries contain business logic, application screens, etc. + +This categorization is a good starting point, but other library types are quite common too (e.g., mock libraries). It's a good idea to establish naming conventions (e.g., `utilities-testing`, `components-buttons`). Having them helps developers explore the code and feel comfortable no matter where they are in the repository. + +### Managing Dependencies + +For a large organization it's crucial to establish how projects can depend on each other. For instance: + +- Libraries with a broader scope (e.g., `shared/ui`) should not depend on the libraries with narrower scope (e.g., `happynrwlapp/search/utils-testing`). +- Component libraries should only depend on other component libraries and utility libraries, but should not depend feature libraries. + +Nx provides a feature called tags that can be used to codify and statically-enforce these rules. Read more about tags [here](/{{framework}}/structure/monorepo-tags). + +## Code Ownership + +It's crucial for a large company with multiple teams contributing to the same repository to establish clear code ownership. + +Since Nx allows us to group apps and libs in directories, those directories can become code-ownership boundaries. That's why the structure of an Nx workspace often reflects the structure of an organization. GitHub users can use the `CODEOWNERS` file for that. + +``` +/libs/happynrwlapp julie-happynrwlapp-lead +/apps/happynrwlapp julie-happynrwlapp-lead +/libs/shared/ui hank-the-ui-guy +/libs/shared/utils-testing julie,hank +``` + +## Enforcing Best Practices + +When we have 10 people working on an app in the same room, we can agree on best practices over lunch. We can also make sure the team follows them by reviewing each other's PRs. For a team of a hundred located in different cities, this no longer works. + +With Nx, we can help teams adopt best practices by using workspace generators and workspace lint checks. + +### Workspace Generators + +Generators is a library used by Nx to do code generation. `nx g lib mylib` invokes the lib generator from the default collection. Generators are a great way to codify conventions and best practices. Unfortunately, creating a custom generators collection is not very straightforward, so few do it. + +Nx simplifies it. With Nx, we can create custom generators in the `tools/generators` folder and invoke them without having to do compile, build, deploy anything. + +Read more about workspace generators in the Workspace Generators guide. + +### Workspace Lint Checks + +Custom lint checks is another great way to enforce best practices. We can create custom lint checks in the `tools/lint` directory and then register them in `tslint.json`or `.eslintrc.json`. + +## Developer Workflow + +Embracing the monorepo-style development often requires some changes to the development workflow. + +**Our CI should run the following checks:** + +- It checks that the changed code is formatted properly. (`nx format:check`) +- It runs lint checks for all the projects affected by a PR/commit. +- It runs unit tests for all the projects affected by a PR/commit. +- It runs e2e tests for all the apps affected by a PR/commit. +- It rebuilds all the apps affected by a PR/commit. + +Note `all the projects affected by a PR/commit`. This is very important. Monorepo-style development only works if we rebuild, retest, and relint only the projects that can be affected by our changes. If we instead retest everything, we will get the the following problems: + +- The performance of CI checks will degrade over time. The time it takes to run the CI checks should be proportional to the impact of the change, not the size of the repo. +- We will be affected by the code your change didn’t touch + +We should utilize `affected:*` commands to build and test projects. Read more about them [here](/{{framework}}/cli/affected). + +### Trunk-based development + +Monorepo-style development works best when used with trunk-based development. + +When using trunk-based development, we have a single main branch (say `master`) where every team submits their code. And +they do it as soon as possible. So if someone works on a large feature, they split it into a few small changes that can be integrated into master in a week. In other words, when using trunk-based development, teams can create branches, but they are short-lived and focus on a specific user story. + +One issue folks often raise in regards to trunk-based development is "things change under you while you are trying to create a release". This can definitely happen, especially when manual testing is involved. To mitigate we can create a release branch where we would cherry-pick commits from `master` to. With this, we can still frequently merge code into `master` and have our release isolated from changes made by other teams. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-tags.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-tags.md new file mode 100644 index 0000000000..526f0b53c2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/monorepo-tags.md @@ -0,0 +1,109 @@ +# Imposing Constraints on the Dependency Graph + +If you partition your code into well-defined cohesive units, even a small organization will end up with a dozen apps and dozens or hundreds of libs. If all of them can depend on each other freely, the chaos will ensue, and the workspace will become unmanageable. + +To help with that Nx uses code analyses to make sure projects can only depend on each other's well-defined public API. It also allows you to declaratively impose constraints on how projects can depend on each other. + +## Tags + +Nx comes with a generic mechanism for expressing constraints: tags. + +First, use `nx.json` to annotate your projects with tags. In this example, we will use three tags: `scope:client`. `scope:admin`, `scope:shared`. + +```json +{ + "npmScope": "myorg", + "implicitDependencies": { + "package.json": "*", + "tsconfig.json": "*", + "nx.json": "*" + }, + "projects": { + "client": { + "tags": ["scope:client"], + "implicitDependencies": [] + }, + "client-e2e": { + "tags": ["scope:client"], + "implicitDependencies": ["client"] + }, + "admin": { + "tags": ["scope:admin"], + "implicitDependencies": [] + }, + "admin-e2e": { + "tags": ["scope:admin"], + "implicitDependencies": ["admin"] + }, + "client-feature-main": { + "tags": ["scope:client"], + "implicitDependencies": [] + }, + "admin-feature-permissions": { + "tags": ["scope:admin"], + "implicitDependencies": [] + }, + "components-shared": { + "tags": ["scope:shared"], + "implicitDependencies": [] + } + } +} +``` + +Next open the top-level `.eslintrc.json` or `tslint.json` to add the constraints. + +```json +{ + "nx-enforce-module-boundaries": [ + true, + { + "allow": [], + "depConstraints": [ + { + "sourceTag": "scope:shared", + "onlyDependOnLibsWithTags": ["scope:shared"] + }, + { + "sourceTag": "scope:admin", + "onlyDependOnLibsWithTags": ["scope:shared", "scope:admin"] + }, + { + "sourceTag": "scope:client", + "onlyDependOnLibsWithTags": ["scope:shared", "scope:client"] + } + ] + } + ] +} +``` + +With these constraints in place, `scope:client` projects can only depend on other `scope:client` projects or on `scope:shared` projects. And `scope:admin` projects can only depend on other `scope:admin` projects or on `scope:shared` projects. So `scope:client` and `scope:admin` cannot depend on each other. + +Projects without any tags cannot depend on any other projects. If you add the following, projects without any tags will be able to depend on any other project. + +```json +{ + "sourceTag": "*", + "onlyDependOnLibsWithTags": ["*"] +} +``` + +If you try to violate the constrains, you will get an error: + +``` +A project tagged with "scope:admin" can only depend on projects tagged with "scoped:shared" or "scope:admin". +``` + +### Exceptions + +The `"allow": []` are the list of imports that won't fail linting. + +- `"allow": ['@myorg/mylib/testing']` allows importing `'@myorg/mylib/testing'`. +- `"allow": ['@myorg/mylib/*']` allows importing `'@myorg/mylib/a'` but not `'@myorg/mylib/a/b'`. +- `"allow": ['@myorg/mylib/**']` allows importing `'@myorg/mylib/a'` and `'@myorg/mylib/a/b'`. +- `"allow": ['@myorg/**/testing']` allows importing `'@myorg/mylib/testing'` and `'@myorg/nested/lib/testing'`. + +## Multiple Dimensions + +The example above shows using a single dimension: `scope`. It's the most commonly used one. But you can find other dimensions useful. You can define which projects contain components, state management code, and features, so you, for instance, can disallow projects containing dumb UI components to depend on state management code. You can define which projects are experimental and which are stable, so stable applications cannot depend on experimental projects etc. You can define which projects have server-side code and which have client-side code to make sure your node app doesn't bundle in your frontend framework. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-logo.png new file mode 100644 index 0000000000..f1e2703531 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-plugin.md new file mode 100644 index 0000000000..94dffb3007 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/nest-plugin.md @@ -0,0 +1,199 @@ +# Nest Plugin + +![NestJS logo](/shared/nest-logo.png) + +Nest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers: + +- It has excellent TypeScript support. +- Its dependency injection system is similar to the one in Angular. +- It emphasises testability. +- Its configuration APIs are similar to Angular as well. + +Many conventions and best practices used in Angular applications can be also be used in Nest. + +## Installing the Nest Plugin + +Installing the Nest plugin to a workspace can be done with the following: + +```shell script +yarn add -D @nrwl/nest +``` + +```shell script +npm install -D @nrwl/nest +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/nest:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ +    └── nest-app/ +       ├── jest.config.js +       ├── src/ +       │   ├── app/ +       │   │   ├── app.controller.ts +       │   │   ├── app.controller.spec.ts +       │   │   ├── app.module.ts +       │   │   ├── app.service.ts +       │   │   └── app.service.spec.ts +       │   ├── assets/ +       │   ├── environments/ +       │   └── main.ts +       ├── tsconfig.app.json +       ├── tsconfig.json +       ├── tsconfig.spec.json +       └── tslint.json +``` + +The `main.ts` content should look similar to this: + +```typescript +import { NestFactory } from '@nestjs/core'; + +import { AppModule } from './app/app.module'; + +async function bootstrap() { + const app = await NestFactory.create(AppModule); + const globalPrefix = 'api'; + app.setGlobalPrefix(globalPrefix); + const port = process.env.port || 3333; + await app.listen(port, () => { + console.log('Listening at http://localhost:' + port + '/' + globalPrefix); + }); +} + +bootstrap(); +``` + +#### Application Proxies + +Generating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/nest:application --frontendProject my-angular-app +``` + +### Application commands + +When a Nest application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Nest application to be rebuilt automatically. +Nest applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nestjs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +##### Waiting for other builds + +Setting the `waitUntilTargets` option with an array of projects (with the following format: `"project:architect"`) will execute those commands before serving the Nest application. + +#### lint + +The lint command will run linting within the scope of the Nest app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Nest app. + +```shell script +nx test +``` + +## Libraries + +Nest libraries are a good way to separate features within your organization. To create a Nest library run the following command: + +```shell script +nx generate @nrwl/nest:library +``` + +Nest libraries can also be generated with an included controller, service or making the module global with their respective flags. + +```shell script +nx generate @nrwl/nest:library [--controller] [--service] [--global] + +``` + +#### Buildable libraries + +Libraries can also be enabled to be built separately from apps. To create a buildable library, add the `--buildable` flag to the generate command above. + +```shell script +nx generate @nrwl/nest:library --buildable +``` + +### Library commands + +When a Nest library is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### lint + +The lint command will run linting within the scope of the Nest library. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Nest library. + +```shell script +nx test +``` + +> Note: By default, Nest libraries are generated with Jest's test environment set to `node` + +#### build + +The build command will only be available if the library was generated with the `--buildable` flag. + +Buildable Nest libraries use TypeScript to compile the source. The tsconfig files that are generated with the library allow customization of the compiled output. + +```shell script +nx build +``` + +## Nest Generators + +The Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--sourceRoot` flag should be used for all Nest generators. + +> The `--sourceRoot` command should point to the source directory of a Nest library or application within an Nx workspace. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/next-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/next-plugin.md new file mode 100644 index 0000000000..36b0f19ca5 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/next-plugin.md @@ -0,0 +1,73 @@ +# Next.js Plugin + +The Nx Plugin for Next.js contains executors and generators for managing Next.js applications and libraries within an Nx workspace. It provides: + +- Scaffolding for creating, building, serving, linting, and testing Next.js applications. +- Integration with building, serving, and exporting a Next.js application. +- Integration with React libraries within the workspace. + +## Installing the Next.js Plugin + +Installing the Next plugin to a workspace can be done with the following: + +```shell script +yarn add -D @nrwl/next +``` + +```shell script +npm install -D @nrwl/next +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/next:application +``` + +This creates the following app structure: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── pages/ +│   │   │   ├── index.css +│   │   │   └── index.tsx +│   │   ├── jest.conf.js +│   │   ├── tsconfig.json +│   │   ├── tsconfig.spec.json +│   │   └── .eslintrc.json +│   └── myapp-e2e/ +│   │   ├── src/ +│   │   │   ├── integrations/ +│   │   │   │   └── app.spec.ts +│   │   │   ├── fixtures/ +│   │   │   ├── plugins/ +│   │   │   └── support/ +│   │   ├── cypress.json +│   │   ├── tsconfig.e2e.json +│   │   └── .eslintrc.json +├── libs/ +├── workspace.json +├── nx.json +├── package.json +├── tools/ +├── tsconfig.json +└── .eslintrc.json +``` + +## See Also + +- [Using Next.js](https://nextjs.org/docs/getting-started) + +## Executors / Builders + +- [build](/{{framework}}/next/build) - Builds a Next.js application +- [server](/{{framework}}/next/server) - Builds and serves a Next.js application +- [export](/{{framework}}/next/export) - Export a Next.js app. The exported application is located at `dist/$outputPath/exported` + +## Generators + +- [application](/{{framework}}/next/application) - Create an Next.js application diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/node-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/node-plugin.md new file mode 100644 index 0000000000..ce676139ef --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/node-plugin.md @@ -0,0 +1,153 @@ +# Node Plugin + +The Node Plugin contains generators and executors to manage Node applications within an Nx workspace. + +## Installing the Node Plugin + +Installing the Node plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/node +``` + +```shell script +#npm +npm install -D @nrwl/node +``` + +## Applications + +Generating new applications can be done with the following: + +```shell script +nx generate @nrwl/node:application +``` + +This creates the following app structure: + +```treeview +my-org/ +├── apps/ + └── node-app/ +    ├── jest.config.js +    ├── src/ +    │   ├── app/ +    │   ├── assets/ +    │   ├── environments/ +    │   │   ├── environment.prod.ts +    │   │   └── environment.ts +    │   └── main.ts +    ├── tsconfig.app.json +    ├── tsconfig.json +    ├── tsconfig.spec.json +   └── tslint.json +``` + +From here files can be added within the `app` folder. +Make sure to import any files within the `main.ts` file so that they can be executed when the application is ran. + +#### Application Proxies + +Generating Node applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for. + +```shell script +nx generate @nrwl/node:application --frontendProject my-react-app +``` + +### Application commands + +When a Node application is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### build + +```shell script +nx build +``` + +The build command will compile the application using Webpack. It supports a production configuration by building with the following command: + +```shell script +nx build --configuration=production +``` + +Additional configurations can be added in the workspace.json. Changing the `--configuration` flag with the new configuration name will run that config. + +#### serve + +```shell script +nx serve +``` + +The serve command runs the `build` target, and executes the application. + +By default, the serve command will run in watch mode. This allows code to be changed, and the Node application to be rebuilt automatically. +Node applications also have the `inspect` flag set, so you can attach your debugger to the running instance. + +##### Debugging + +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. + +For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients). + +#### lint + +The lint command will run linting within the scope of the Node app. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Node app. + +```shell script +nx test +``` + +## Libraries + +Node libraries are a good way to separate features within your organization. To create a Node library run the following command: + +```shell script +nx generate @nrwl/node:library +``` + +#### Buildable libraries + +Libraries can also be enabled to be built separately from apps. To create a buildable library, add the `--buildable` flag to the generate command above. + +```shell script +nx generate @nrwl/node:library --buildable +``` + +### Library commands + +When a Node library is added to the workspace.json (or angular.json), the following architect commands are available for execution: + +#### lint + +The lint command will run linting within the scope of the Node library. + +```shell script +nx lint +``` + +#### test + +Test will execute Jest tests within the scope of the Node library. + +```shell script +nx test +``` + +#### build + +The build command will only be available if the library was generated with the `--buildable` flag. + +Buildable Node libraries use TypeScript to compile the source. The tsconfig files that are generated with the library allow customization of the compiled output. + +```shell script +nx build +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-logo.png new file mode 100644 index 0000000000..11d0c0758f Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-screenshot.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-screenshot.png new file mode 100644 index 0000000000..0a444ee0d5 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-console-screenshot.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-plugin.md new file mode 100644 index 0000000000..47562ea004 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/nx-plugin.md @@ -0,0 +1,221 @@ +# Nx Plugins + +Nx plugins are npm packages that contain generators and executors to extend a Nx workspace. Generators are blueprints to create new files from templates, and executors run those files. These plugins also update the `nx.json` when generating new libs or apps. + +> A list of plugins that is maintained by Nrwl is found in the [Nrwl/nx repo](https://github.com/nrwl/nx/tree/master/packages). \ +> A list of custom plugins created by the community is found in the [Community](/nx-community) section. +> Plugins are written using Nx Devkit. **Read [Nx Devkit](/{{framework}}/core-concepts/nx-devkit) for more information.** + + + +## Generating a Plugin + +To get started with building a Nx Plugin, run the following command: + +```bash +npx create-nx-plugin my-org --pluginName my-plugin +``` + +This command creates a brand new workspace, and sets up a pre-configured plugin with the specified name. + +## Workspace Structure + +After executing the above command, the following tree structure is created: + +```treeview +my-org/ +├── e2e/ +│ └── my-plugin-e2e/ +│ ├── jest.config.js +│ ├── tests/ +│ │ └── my-plugin.test.ts +│ ├── tsconfig.json +│ └── tsconfig.spec.json +├── packages/ +│ └── my-plugin/ +│ ├── README.md +│ ├── executors.json +│ ├── collection.json +│ ├── jest.config.js +│ ├── package.json +│ ├── src/ +│ │ ├── executors/ +│ │ │ └── my-plugin/ +│ │ │ ├── executor.spec.ts +│ │ │ ├── executor.ts +│ │ │ ├── schema.d.ts +│ │ │ └── schema.json +│ │ ├── index.ts +│ │ └── generators/ +│ │ └── my-plugin/ +│ │ ├── files/ +│ │ │ └── src/ +│ │ │ └── index.ts.__template__ +│ │ ├── schema.d.ts +│ │ ├── schema.json +│ │ ├── generator.spec.ts +│ │ └── generator.ts +│ ├── tsconfig.json +│ ├── tsconfig.lib.json +│ └── tsconfig.spec.json +├── tools +│ ├── generators/ +│ └── tsconfig.tools.json +├── jest.config.js +├── nx.json +├── package.json +├── tsconfig.json +├── workspace.json +└── yarn.lock +``` + +> If you do not want to create a new workspace, install the `@nrwl/nx-plugin` dependency in an already existing workspace with npm or yarn. Then run `nx g @nrwl/nx-plugin:plugin [pluginName]`. + +A new plugin is created with a default generator, executor, and e2e app. + +## Generator + +The generated generator contains boilerplate that will do the following: + +- Normalize a schema (the options that the generator accepts) +- Update the `workspace.json` +- Add the plugin's project to the `nx.json` file +- Add files to the disk using templates + +There will be a exported default function that will be the main entry for the generator. + +### Generator options + +The `schema.d.ts` file contains all the options that the generator supports. By default, it includes `directory`, `tags`, and `name` as the options. If more options need to be added, please update this file and the `schema.json` file. + +> Note: The `schema.d.ts` file is used for type checking inside the implementation file. It should match the properties in `schema.json`. + +### Adding more generators + +To add more generators to the plugin, run the following command: +`nx generate @nrwl/nx-plugin:generator [generatorName] --project=[pluginName]`. + +This will scaffold out a new generator and update the necessary files to support it. + +### Generator Testing + +The generator spec file includes boilerplate to help get started with testing. This includes setting up an empty workspace. + +These tests should ensure that files within the tree (created with `createTreeWithEmptyWorkspace`) are in the correct place, and contain the right content. + +Full E2Es are supported (and recommended) and will run everything on the file system like a user would. + +## Executor + +The default executor is set up to just emit a console log. Some examples of what an executor can do are: + +- Support different languages, (Java, Go, Python, C#) +- Compile new UI framework components +- Deploy an app on a CDN +- Publish to NPM +- and many more! + +### Adding more executors + +To add more executors to the plugin, run the following command: +`nx generate @nrwl/nx-plugin:executor [executor] --project=[pluginName]`. + +This will scaffold out a new generator and update the necessary files to support it. + +### Executor testing + +The executor spec file contains boilerplate to run the default exported function from the executor. + +These tests should make sure that the executor is executing and calling the functions that it relies on. + +Full E2Es are supported (and recommended) and will run everything on the file system like a user would. + +## Testing your plugin + +One of the biggest benefits that the Nx Plugin package provides is support for E2E testing. + +When the E2E app runs, a temporary E2E directory is created in the root of the workspace. This directory is a blank Nx workspace, and will have the plugin's built package installed locally. + +### E2E Testing file + +When the plugin is generated, a test file is created in the `my-plugin-e2e` app. Inside this test file, there are already tests for making sure that the executor ran, checking if directories are created with the `--directory` option, and checking if tags are added to `nx.json`. + +We'll go over a few parts of a test file below: + +```typescript +it('should create my-plugin', async (done) => { + const plugin = uniq('my-plugin'); + ensureNxProject('@my-org/my-plugin', 'dist/packages/my-plugin'); + await runNxCommandAsync(`generate @my-org/my-plugin:myPlugin ${plugin}`); + + const result = await runNxCommandAsync(`build ${plugin}`); + expect(result.stdout).toContain('Executor ran'); + + done(); +}); +``` + +- The `uniq` function creates a random name with the prefix and a random number. +- The `ensureNxProject` is the function that will create the temporary directory. It takes two arguments, the plugin package name and the dist directory of when it's built. +- The `runNxCommandAsync` will execute a `nx` command in the E2E directory. + +There are additional functions that the `@nrwl/nx-plugin/testing` package exports. Most of them are file utilities to manipulate and read files in the E2E directory. + +## Including Assets + +Sometimes you might want to include some assets with the plugin. This might be a image or some additional binaries. + +To make sure that assets are copied to the dist folder, open the `workspace.json` file, and find the plugin's project. Inside the `build` property, add additional assets. By default, all `.md` files in the root, all non-ts files in folders, and the `collection.json` and `executors.json` files are included. + +```json +"build": { + "executor": "@nrwl/node:package", + "options": { + // shortened... + "assets": [ + "packages/my-plugin/*.md", + { + "input": "./packages/my-plugin/src", + "glob": "**/*.!(ts)", + "output": "./src" + }, + { + "input": "./packages/my-plugin", + "glob": "collection.json", + "output": "." + }, + { + "input": "./packages/my-plugin", + "glob": "executors.json", + "output": "." + } + ] + } +} +``` + +## Publishing your Nx Plugin + +To publish your plugin follow these steps: + +1. Build your plugin with the command `nx run my-plugin:build` +1. `npm publish ./dist/package/my-plugin` and follow the prompts from npm. +1. That's it! + +> Note: currently you will have to modify the `package.json` version by yourself or with a tool. + +After that, you can then install your plugin like any other npm package, +`npm i -D @my-org/my-plugin` or `yarn add -D @my-org/my-plugin`. + +### Listing your Nx Plugin + +Nx provides a utility (`nx list`) that lists both core and community plugins. To submit your plugin, please follow the steps below: + +- Fork the [Nx repo](https://github.com/nrwl/nx/fork) (if you haven't already) +- Update the [`community/approved-plugins.json` file](https://github.com/nrwl/nx/blob/master/community/approved-plugins.json) with a new entry for your plugin that includes name, url and description +- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]` +- push your changes, and run `yarn submit-plugin` + +> The `yarn submit-plugin` command automatically opens the Github pull request process with the correct template. + +We will then verify the plugin, offer suggestions or merge the pull request! diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/plugins-overview.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/plugins-overview.md new file mode 100644 index 0000000000..0ecf7e5b15 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/plugins-overview.md @@ -0,0 +1,42 @@ +# Plugins + +Nx plugins are npm packages that contain generators and executors to extend an Nx workspace. Generators are blueprints to create or modify code, and executors perform actions on the code. + +The [Workspace](/{{framework}}/workspace/nrwl-workspace-overview) plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it. + +There are plugins for application frameworks like [Angular](/{{framework}}/angular/overview), [Express](/{{framework}}/express/overview), [Gatsby](/{{framework}}/gatsby/overview), [Nest](/{{framework}}/nest/overview), [Next](/{{framework}}/next/overview), [Node](/{{framework}}/node/overview), [React](/{{framework}}/react/overview) and [Web](/{{framework}}/web/overview). There are also plugins to help manage tooling ([Cypress](/{{framework}}/cypress/overview), [Jest](/{{framework}}/jest/overview), [Linter](/{{framework}}/linter/eslint) and [Storybook](/{{framework}}/storybook/overview)). + +The [Nx Plugin](/{{framework}}/nx-plugin/overview) plugin helps you build your own custom plugins. + +## nx list + +Use the `nx list` command to see installed and available plugins. Both Nrwl maintained (`@nrwl/something`) and community plugins are listed. + +```bash +❯ nx list +> NX Installed plugins: + @nrwl/angular (builders,schematics) + @nrwl/cypress (builders,schematics) + @nrwl/jest (builders,schematics) + @nrwl/linter (builders) + @nrwl/nest (schematics) + @nrwl/node (builders,schematics) + @nrwl/nx-cloud (schematics) + @nrwl/workspace (builders,schematics) +> NX Also available: + @nrwl/express (builders,schematics) + @nrwl/next (builders,schematics) + @nrwl/react (builders,schematics) + @nrwl/storybook (builders,schematics) + @nrwl/web (builders,schematics) +> NX Community plugins: + @nxtend/ionic-react - An Nx plugin for developing Ionic React applications and libraries + @angular-architects/ddd - Nx plugin for structuring a monorepo with domains and layers + @offeringsolutions/nx-karma-to-jest - Nx plugin for replacing karma with jest in an Nx workspace + @flowaccount/nx-serverless - Nx plugin for node/angular-universal schematics and deployment builders in an Nx workspace + @dev-thought/nx-deploy-it - Nx plugin to deploy applications on your favorite cloud provider +``` + +## See Also + +[Nx Community Plugins](/nx-community) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/prettier-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/prettier-logo.png new file mode 100644 index 0000000000..59bb947f29 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/prettier-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/react-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/react-plugin.md new file mode 100644 index 0000000000..c67c505130 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/react-plugin.md @@ -0,0 +1,90 @@ +# Nx Plugin for React + +The Nx Plugin for React contains generators for managing React applications and libraries within an Nx workspace. It provides: + +- Integration with libraries such as Jest, Cypress, and Storybook. +- Scaffolding for state management with Redux Toolkit libraries. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the React plugin + +Adding the React plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/react +``` + +```shell script +#npm +npm install -D @nrwl/react +``` + +> Note: You can create a new workspace that has React set up by doing `npx create-nx-workspace@latest --preset=react` + +The file structure for a React application looks like: + +```treeview +myorg/ +├── apps/ +│   ├── myapp/ +│   │   ├── src/ +│   │   │   ├── app/ +│   │   │   ├── assets/ +│   │   │   ├── environments/ +│   │   │   ├── favicon.ico +│   │   │   ├── index.html +│   │   │   ├── main.tsx +│   │   │   ├── polyfills.ts +│   │   │   └── styles.css +│   │   ├── browserslist +│   │   ├── jest.config.js +│   │   ├── tsconfig.app.json +│   │   ├── tsconfig.json +│   │   └── tsconfig.spec.json +│   └── myapp-e2e/ +│      ├── src/ +│      │   ├── fixtures/ +│      │   │   └── example.json +│      │   ├── integration/ +│      │   │   └── app.spec.ts +│      │   ├── plugins/ +│      │   │   └── index.ts +│      │   └── support/ +│      │      ├── app.po.ts +│      │      ├── commands.ts +│      │      └── index.ts +│      ├── cypress.json +│      ├── tsconfig.e2e.json +│      └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +## See Also + +- [Using Cypress](/{{framework}}/cypress/overview) +- [Using Jest](/{{framework}}/jest/overview) +- [Using Storybook](/{{framework}}/storybook/overview) + +## Executors / Builders + +React applications are built using the executors from the `@nrwl/web` plugin. + +- [build](/{{framework}}/web/build) - Builds a web components application +- [dev-server](/{{framework}}/web/package) - Builds and serves a web application +- [package](/{{framework}}/web/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Generators + +- [application](/{{framework}}/react/application) - Create an React application +- [component](/{{framework}}/react/component) - Create an React library +- [library](/{{framework}}/react/library) - Create an React library +- [redux](/{{framework}}/react/redux) - Generate a Redux slice for a project +- [storybook-configuration](/{{framework}}/react/storybook-configuration) - Set up Storybook for a react library diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/refresh-light.svg b/nx-dev/data-access-documents/src/data/11.4.0/shared/refresh-light.svg new file mode 100644 index 0000000000..e034574819 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/refresh-light.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/running-custom-commands.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/running-custom-commands.md new file mode 100644 index 0000000000..714823828e --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/running-custom-commands.md @@ -0,0 +1,61 @@ +# Running Custom Commands + +This recipe will show how to run any terminal command within the nx build-chain. + +## Steps + +##### 1. Define the terminal command to be run + +The command we want to run for each project is: + +```bash +make hello +``` + +With this `Makefile` in the root of the project: + +```shell script +hello: + echo "Hello, world!" +``` + +##### 2. Update `workspace.json` + +For each project for which you want to enable `make`, add a target in `workspace.json`: + +```json +// ... +"my-app": { + "targets": { + "make": { + "executor": "@nrwl/workspace:run-commands", + "options": { + "commands": [ + { + "command": "make hello" + } + ] + } + } + // ... + } +} +``` + +For more information, see the [run-commands api doc](/{{framework}}/workspace/run-commands-executor). + +##### 3. Trigger the executor from the terminal + +To run the executor for a single project: + +```bash +nx run my-app:make +``` + +To run the executor for all affected projects: + +```bash +nx affected --target=make +``` + +For more information, see the [nx affected](/{{framework}}/cli/affected). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/storybook-logo.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/storybook-logo.png new file mode 100644 index 0000000000..9201193134 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/storybook-logo.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-builders.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-builders.md new file mode 100644 index 0000000000..79b10c71b2 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-builders.md @@ -0,0 +1,268 @@ +# Creating Nx Executors or Angular Devkit Builders in Your Nx Workspace + +Creating Nx Executors/Angular Devkit Builders for your workspace standardizes scripts that are run during your development/building/deploying tasks in order to enable Nx's `affected` command and caching capabilities. + +This guide will show you how to create, run, and customize executors/builders within your Nx workspace. In the examples, we'll use the trivial use-case of an `echo` command. + +## Creating a Builder with @angular-devkit + +> Note: In this article, we'll refer to executors that use the `@angular-devkit` as Angular Devkit Builders. + +Your executor should be created within the `tools` directory of your Nx workspace like so: + +```treeview +happynrwl/ +├── apps/ +├── libs/ +├── tools/ +│ └── executors/ +│ └── echo/ +│ ├── builder.json +│ ├── impl.ts +│ ├── package.json +│ └── schema.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +### schema.json + +This file will describe the options being sent to the builder (very similar to the `schema.json` file of generators). + +```json +{ + "$schema": "http://json-schema.org/schema", + "type": "object", + "properties": { + "textToEcho": { + "type": "string", + "description": "Text To Echo" + } + } +} +``` + +This example describes a single option for the builder that is a `string` called 'textToEcho'. When using this builder, we'll specify a 'textToEcho' property inside the options. + +In our `impl.ts` file, we're creating an `Options` interface that matches the json object being described here. + +### impl.ts + +The `impl.ts` contains the actual code for your builder. Your builder should use the `createBuilder` function of the `@angular-devkit/architect` package to create a builder that can be run via the Nx CLI tools. + +```typescript +import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; +import * as childProcess from 'child_process'; +import { Observable } from 'rxjs'; +import { json } from '@angular-devkit/core'; + +interface Options extends json.JsonObject { + textToEcho: string; +} + +export default createBuilder((_options: Options, context) => { + context.logger.info(`Executing "echo"...`); + context.logger.info(`Options: ${JSON.stringify(_options, null, 2)}`); + const child = childProcess.spawn('echo', [_options.textToEcho]); + return new Observable((observer) => { + child.stdout.on('data', (data) => { + context.logger.info(data.toString()); + }); + child.stderr.on('data', (data) => { + context.logger.error(data.toString()); + }); + child.on('close', (code) => { + context.logger.info(`Done.`); + observer.next({ success: code === 0 }); + observer.complete(); + }); + }); +}); +``` + +See the [official Angular documentation on builders](https://angular.io/guide/cli-builder) for more clarification on creating builders. + +Also note that [Node’s `childProcess`](https://nodejs.org/api/child_process.html) is likely to be used in most cases. + +Part of the power of the architect API is the ability to compose builders via existing build targets. This way you can combine other builders from your workspace into one which could be helpful when the process you’re scripting is a combination of other existing builders provided by the CLI or other custom-builders in your workspace. + +Here's an example of this (from a hypothetical project), that will serve an api (project name: "api") in watch mode, then serve a frontend app (project name: "web-client") in watch mode: + +```typescript +import { + BuilderContext, + BuilderOutput, + createBuilder, + scheduleTargetAndForget, + targetFromTargetString, +} from '@angular-devkit/architect'; +import { concat } from 'rxjs'; +import { concatMap, map } from 'rxjs/operators'; +interface Options extends json.JsonObject {} + +export default createBuilder((_options: Options, context: BuilderContext) => { + return concat( + scheduleTargetAndForget( + context, + targetFromTargetString('api:serve'), + { watch: true } + ), + scheduleTargetAndForget( + context, + targetFromTargetString('web-client:serve'), + { watch: true } + ) + ).pipe( + map(([apiBuilderContext, webClientBuilderContext]) => + ({ success: apiBuilderContext.success && webClientBuilderContext.success}) + ) + ); +``` + +For other ideas on how to create your own builders, you can always check out Nx's own open-source builders as well! + +(e.g. our [cypress builder](https://github.com/nrwl/nx/blob/master/packages/cypress/src/builders/cypress/cypress.impl.ts)) + +### builder.json + +The `builder.json` file provides the description of your builder to the CLI. + +```json +{ + "builders": { + "echo": { + "implementation": "./impl", + "schema": "./schema.json", + "description": "Runs `echo` (to test builders out)." + } + } +} +``` + +Note that this `builder.json` file is naming our builder 'echo' for the CLI's purposes, and maping that name to the given implemetation file and schema. + +### package.json + +This is all that’s required from the `package.json` file: + +```json +{ + "builders": "./builder.json" +} +``` + +## Creating an Nx Executor + +Creating an Nx Executor is in principle nearly identical to the Angular Devkit Builder example in the section above, we'll explain in this section the few differences involved. + +### Marking the Executor as an Nx Executor + +The first difference to adjust is to mark the executor as an Nx Executor in the schema. To do this, we'll need to add the `cli` property to the builder's schema, and give it the value `"nx"`: + +```json +{ + "$schema": "http://json-schema.org/schema", + "type": "object", + "cli": "nx", + "properties": { + "textToEcho": { + "type": "string", + "description": "Text To Echo" + } + } +} +``` + +### Implementing an Executor Without the Angular Devkit + +Your executor's implementation must consist of a function that takes an options object and returns a `Promise<{ success: boolean }>`. Given the echo implementation provided in the Angular Devkit Builder section above, our Nx executor would look like this: + +```typescript +import * as childProcess from 'child_process'; + +interface Options { + textToEcho: string; +} + +export default async function ( + _options: Options +): Promise<{ success: boolean }> { + const child = childProcess.spawn('echo', [_options.textToEcho]); + return new Promise<{ success: boolean }>((res) => { + child.on('close', (code) => { + res({ success: code === 0 }); + }); + }); +} +``` + +## Compiling and Running your Builder + +After your files are created, you can compile your builder with `tsc` (which should be available as long as you've installed Typescript globally: `npm i -g typescript`): + +```sh +tsc tools/builders/echo/impl +``` + +This will create the `impl.js` file in your file directory, which will serve as the artifact used by the CLI. + +Our last step is to add this builder to a given project’s `architect` object in your project's `workspace.json` or `angular.json` file. The example below adds this builder to a project named 'platform': + +```json +{ + //... + "projects": { + "platform": { + //... + "architect": { + "build": { + // ... + }, + "serve": { + // ... + }, + "lint": { + // ,,, + }, + "echo": { + "executor": "./tools/builders/echo:echo", + "options": { + "textToEcho": "Hello World" + } + } + } + } + } +} +``` + +Note that the format of the `executor` string here is: `${Path to directory containing the builder's package.json}:${builder name}`. + +Finally, we may run our builder via the CLI as follows: + +```sh +nx run platform:echo +``` + +To which we'll see the console output: + +```sh +> ng run platform:echo +Executing "echo"... +Hello World + +Done. +``` + +## Debugging Builders + +As part of Nx's computation cache process, Nx forks the node process, which can make it difficult to debug a builder command. Follow these steps to debug an executor: + +1. Make sure VSCode's `debug.node.autoAttach` setting is set to `On`. +2. Find the executor code and set a breakpoint. +3. Use node in debug to execute your executor command, replacing `nx` with the internal `tao` script. + +```bash +node --inspect-brk node_modules/.bin/tao build best-app +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-generators.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-generators.md new file mode 100644 index 0000000000..c10ad54af6 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/tools-workspace-generators.md @@ -0,0 +1,309 @@ +# 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. + +```sh +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.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. + +```sh +nx workspace-generator my-generator mylib +``` + +## Running a workspace schematic created with @angular-devkit + +Generators that are created using the `@angular-devkit` are called schematics. Workspace schematics that have been created with the `@angular-devkit` will omit the `"cli": "nx"` property in `schema.json`. Nx will recognize this and correctly run the schematic using the same command as an `@nrwl/devkit` generator. + +```sh +nx workspace-generator my-schematic mylib +``` + +The command is also aliased to the previous `workspace-schematic` command, so this still works: + +```sh +nx workspace-schematic my-schematic mylib +``` + +## Creating custom rules with @angular-devkit + +Generators provide an API for managing files within your workspace. You can use schematics to do things such as create, update, move, and delete files. Files with static or dynamic content can also be created. + +The schematic 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/ +│ ├── schematics +│ | └── my-schematic/ +│ | | └── files +│ | | └── NOTES.md +│ | | ├── index.ts +│ | | └── schema.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +Next, update the `index.ts` file for the schematic, and create different rules for generating a library, and generating the new files. Both rules have access to the available options provided for the schematic. + +```typescript +import { + apply, + chain, + mergeWith, + move, + Rule, + SchematicContext, + Tree, + url, + externalSchematic, +} from '@angular-devkit/schematics'; +import { getProjectConfig } from '@nrwl/workspace'; + +function generateLibrary(schema: any): Rule { + return externalSchematic('@nrwl/workspace', 'lib', { + name: schema.name, + }); +} + +function generateFiles(schema: any): Rule { + return (tree: Tree, context: SchematicContext) => { + context.logger.info('adding NOTES.md to lib'); + + const templateSource = apply(url('./files'), [ + move(getProjectConfig(tree, schema.name).root), + ]); + + return chain([mergeWith(templateSource)])(tree, context); + }; +} + +export default function (schema: any): Rule { + return (tree: Tree, context: SchematicContext) => { + return chain([generateLibrary(schema), generateFiles(schema)])( + tree, + context + ); + }; +} +``` + +The exported function calls the two rules, first creating the library, then creating the additional files in the new library's folder. + +Next, run the schematic: + +> Use the `-d` or `--dry-run` flag to see your changes without applying them. + +```sh +nx workspace-generator my-schematic mylib +``` + +The following information will be displayed. + +```sh +> NX Executing your local schematic: my-schematic + +CREATE libs/mylib/tslint.json (48 bytes) +CREATE libs/mylib/README.md (164 bytes) +CREATE libs/mylib/tsconfig.json (123 bytes) +CREATE libs/mylib/tsconfig.lib.json (172 bytes) +CREATE libs/mylib/src/index.ts (29 bytes) +CREATE libs/mylib/src/lib/mylib.ts (0 bytes) +CREATE libs/mylib/tsconfig.spec.json (273 bytes) +CREATE libs/mylib/jest.config.js (234 bytes) +CREATE libs/mylib/NOTES.md (15 bytes) +UPDATE tsconfig.json (582 bytes) +UPDATE angular.json (4751 bytes) +UPDATE nx.json (438 bytes) +UPDATE package.json (1959 bytes) +``` + +## 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 SchematicOptions { + 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: SchematicOptions) { + 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 an `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. + +## Debugging Workspace generators + +### With Visual Studio Code + +1. Open the Command Pallette 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/data-access-documents/src/data/11.4.0/shared/update.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/update.md new file mode 100644 index 0000000000..534691ce3a --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/update.md @@ -0,0 +1,98 @@ +# Updating Nx + +Nx provides the `migrate` command which help you stay up to date with the latest version of Nx. + +Not only `nx migrate` updates the version of Nx, but it also updates the versions of dependencies which we install such as jest and cypress. You can also use the `migrate` command to update any Nx plugin. + +## How to Migrate + +Migration happens in two steps: + +- Updating `package.json` (and `node_modules`) +- Updating the source code of the repo to match the new versions of packages in `package.json` + +### Step 1: Updating package.json and generating migrations.json + +Run the following: + +```bash +nx migrate latest # same as nx migrate @nrwl/workspace@latest +``` + +You can also specify the name of the package and the version: + +```bash +nx migrate @nrwl/workspace@version # you can also specify version +``` + +This will fetch the specified version of `@nrwl/workspace`, analyze the dependencies and fetch all the dependent packages. The process will keep going until the whole tree of dependencies is resolved. This will result in: + +- `package.json` being updated +- `migrations.json` being generated + +At this point, no packages have been installed, and no other files have been touched. + +Now, you can inspect `package.json` to see if the changes make sense. Sometimes the migration can update some package to the version that is either not allowed or conflicts with with another package. After you are satisfied, run `npm install`, `yarn`, or `pnpm install`. + +### Step 2: Running migrations + +Next, we need to update the repo to match the updated `package.json` and `node_modules`. Every Nx plugin comes with a set of migrations that describe how to update the workspace to make it work with the new version of the plugin. During Step 1 Nx looked at all of the packages being updated and collected their migrations into `migrations.json`. It's important to note that because Nx knows the from and to versions of every package, the `migrations.json` file only contains the relevant migrations. + +Each migration in `migrations.json` updates the source code in the repository. To run all the migrations in order, invoke: + +```bash +nx migrate --run-migrations=migrations.json +``` + +For small projects, running all the migrations at once often succeeds without any issues. For large projects, more flexibility is sometimes needed: + +- You may have to skip a migration. +- You may want to run one migration at a time to address minor issues. +- You may want to reorder migrations. +- You may want to run the same migration multiple time if the process takes a long time and you had to rebase. + +Since you can run `nx migrate --run-migrations=migrations.json` as many times as you want, you can achieve all of that by commenting out and reordering items in `migrations.json`. The migrate process can take a long time, sometimes a day, so it can be useful to commit the migrations file with the partially-updated repo. + +### Step 3: Cleaning up + +After you run all the migrations, you can remove `migration.json` and commit the changes. + +## Advanced Capabilities & Recommendations + +### One Major Version at a Time, Small Steps + +Migrating Jest, Cypress, ESLint, React, Angular, Next etc... is a difficult task. All the tools change at different rates, they can conflict with each other etc.. In addition, every workspace is different. Even though our goal is to let you update any version of Nx to any other version in a single go, sometimes it doesn't work. The following process is better for large workspaces. + +Say you want to migrate from Nx 10.1.0 to Nx 11.0.1. The following steps are more likely to work comparing to `nx migrate 11.0.1`. + +- Run `nx migrate 10.4.5` to update the latest version in the 10x branch. +- Run `npm install` +- Run `nx migrate --run-migrations=migrations.json` +- Next, run `nx migrate 11.0.1` +- Run `npm install` +- Run `nx migrate --run-migrations=migrations.json` + +### Overriding versions + +Sometimes, you may want to use a different version of a package than what Nx recommends. You can do it as follows: + +```bash +nx migrate @nrwl/workspace --to="jest@22.0.0,cypress:3.4.0" +``` + +By default, Nx uses currently installed packages to calculate what migrations need to run. You can override them like this: + +```bash +nx migrate @nrwl/workspace --to="@nrwl/jest@8.0.0" +``` + +### Reverting a failed update + +Updates are best done on a clean git history so that it can be easily reversed if something fails. +We try our best to make sure migrations do not fail but if one does, **please report it** on [Github](https://www.github.com/nrwl/nx/issues/new/). +If an update fails for any reason, you can revert it as you do any other set of changes: + +```bash +git reset --hard # Reset any changes +git clean -fd # Delete newly added files and directories +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/using-builders.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/using-builders.md new file mode 100644 index 0000000000..03ecdb5005 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/using-builders.md @@ -0,0 +1,95 @@ +# Using Executors / Builders + +Executors perform actions on your code. This can include building, linting, testing, serving and many other actions. + +Executors can be written using `@nrwl/devkit` or `@angular-devkit`. Executors written with the `@angular-devkit` are called Builders. + +There are two main differences between an executor and a shell script or an npm script: + +1. Executors encourage a consistent methodology for performing similar actions on unrelated projects. i.e. A developer switching between teams can be confident that `nx build project2` will build `project2` with the default settings, just like `nx build project1` built `project1`. +2. Nx can leverage this consistency to perform the same executor across multiple projects. i.e. `nx affected --target==test` will run the `test` executor on every project that is affected by the current code change. + +## Executor Definitions + +The executors that are available for each project are defined and configured in the `/workspace.json` file. + +```json +{ + "projects": { + "cart": { + "root": "apps/cart", + "sourceRoot": "apps/cart/src", + "projectType": "application", + "generators": {}, + "targets": { + "build": { + "executor": "@nrwl/web:build", + "options": { + "outputPath": "dist/apps/cart", + ... + }, + "configurations": { + "production": { + "sourceMap": false, + ... + } + } + }, + "test": { + "executor": "@nrwl/jest:jest", + "options": { + ... + } + } + } + } + } +} +``` + +> Note: There are a few property keys in `workspace.json` that have interchangeable aliases. You can replace `generators` with `schematics`, `targets` with `architect` or `executor` with `builder`. + +Each project has its executors defined in the `targets` property. In this snippet, `cart` has two executors defined - `build` and `test`. + +> Note: `build` and `test` can be any strings you choose. For the sake of consistency, we make `test` run unit tests for every project and `build` produce compiled code for the projects which can be built. + +Each executor definition has an `executor` property and, optionally, an `options` and a `configurations` property. + +- `executor` is a string of the from `[package name]:[executor name]`. For the `build` executor, the package name is `@nrwl/web` and the executor name is `build`. +- `options` is an object that contains any configuration defaults for the executor. These options vary from executor to executor. +- `configurations` allows you to create presets of options for different scenarios. All the configurations start with the properties defined in `options` as a baseline and then overwrite those options. In the example, there is a `production` configuration that overrides the default options to set `sourceMap` to `false`. + +## Running Executors + +The [`nx run`](/{{framework}}/cli/run) cli command (or the shorthand versions) can be used to run executors. + +```bash +nx run [project]:[command] +nx run cart:build +``` + +As long as your command name doesn't conflict with an existing nx cli command, you can use this short hand: + +```bash +nx [command] [project] +nx build cart +``` + +You can also use a specific configuration preset like this: + +```bash +nx [command] [project] --configuration=[configuration] +nx build cart --configuration=production +``` + +Or you can overwrite individual executor options like this: + +```bash +nx [command] [project] --[optionNameInCamelCase]=[value] +nx build cart --outputPath=some/other/path +``` + +## See Also + +- [`nx affected`](/{{framework}}/cli/affected) +- [`nx run-many`](/{{framework}}/cli/run-many) diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/using-schematics.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/using-schematics.md new file mode 100644 index 0000000000..c842f48632 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/using-schematics.md @@ -0,0 +1,28 @@ +# 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. + +Generators can be written using `@nrwl/devkit` or `@angular-devkit`. Generators written with the `@angular-devkit` are called schematics. To read more about the concepts of `@angular-devkit` schematics, and building an example schematic, see the [Schematics Authoring Guide](https://angular.io/guide/schematics-authoring). + +The [Workspace Generators](/{{framework}}/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](/{{framework}}/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](/{{framework}}/core-concepts/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`](/{{framework}}/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/data-access-documents/src/data/11.4.0/shared/vscode-schematics-debug.png b/nx-dev/data-access-documents/src/data/11.4.0/shared/vscode-schematics-debug.png new file mode 100644 index 0000000000..57efd4b6c1 Binary files /dev/null and b/nx-dev/data-access-documents/src/data/11.4.0/shared/vscode-schematics-debug.png differ diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/web-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/web-plugin.md new file mode 100644 index 0000000000..4d512f80dd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/web-plugin.md @@ -0,0 +1,82 @@ +# Nx Plugin for Web + +The Nx Plugin for Web Components contains generators for managing Web Component applications and libraries within an Nx workspace. It provides: + +- Integration with libraries such as Jest, Cypress, and Storybook. +- Scaffolding for creating buildable libraries that can be published to npm. +- Utilities for automatic workspace refactoring. + +## Adding the Web plugin + +Adding the Web plugin to a workspace can be done with the following: + +```shell script +#yarn +yarn add -D @nrwl/web +``` + +```shell script +#npm +npm install -D @nrwl/web +``` + +> Note: You can create a new workspace that has Web Components set up by doing `npx create-nx-workspace@latest --preset=web-components` + +The file structure for a Web Components application looks like: + +```treeview +myorg/ +├── apps/ +│ ├── todos/ +│ │ ├── src/ +│ │ │ ├── app/ +│ │ │ ├── assets/ +│ │ │ ├── environments/ +│ │ │ ├── favicon.ico +│ │ │ ├── index.html +│ │ │ ├── main.ts +│ │ │ ├── polyfills.ts +│ │ │ └── styles.css +│ │ ├── browserslist +│ │ ├── jest.config.js +│ │ ├── tsconfig.app.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 +│ ├── tsconfig.e2e.json +│ └── tsconfig.json +├── libs/ +├── tools/ +├── README.md +├── workspace.json +├── nx.json +├── package.json +└── tsconfig.json +``` + +## See Also + +- [Using Cypress](/{{framework}}/cypress/overview) +- [Using Jest](/{{framework}}/cypress/overview) + +## Executors / Builders + +- [build](/{{framework}}/web/build) - Builds a web components application +- [dev-server](/{{framework}}/web/dev-server) - Builds and serves a web application +- [package](/{{framework}}/web/package) - Bundles artifacts for a buildable library that can be distributed as an NPM package. + +## Generators + +- [application](/{{framework}}/web/application) - Create an Web Components application diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace-plugin.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace-plugin.md new file mode 100644 index 0000000000..a343267c6f --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace-plugin.md @@ -0,0 +1,15 @@ +# Workspace Plugin + +The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it. + +## Generators + +- [library](/{{framework}}/workspace/library) - Create a plain typescript library +- [move](/{{framework}}/workspace/move) - Move a project to another directory and update all references +- [remove](/{{framework}}/workspace/remove) - Remove a project from the workspace +- [run-commands](/{{framework}}/workspace/run-commands-executor) - Add a target to a project that uses the run-commands executor +- [workspace-generator](/{{framework}}/workspace/workspace-generator) - Scaffold a custom generator for use within your workspace + +## Executors / Builders + +- [run-commands](/{{framework}}/workspace/run-commands-executor) - Execute an arbitrary command line script diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/buildable-and-publishable-libraries.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/buildable-and-publishable-libraries.md new file mode 100644 index 0000000000..10c3ba0943 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/buildable-and-publishable-libraries.md @@ -0,0 +1,34 @@ +# Publishable and Buildable Nx Libraries + +The `--buildable` and `--publishable` options are available on the Nx library generators for the following plugins: + +- Angular +- React +- NestJs +- Node + +This document will look to explain the motivations for why you would use either the `--buildable` or `--publishable` option, as well as the mechanics of how they adjust the result when you add them to your generator. + +## Publishable libraries + +You might use the `--publishable` option when generating a new Nx library if your intention is to distribute it outside the monorepo. + +One typical scenario for this may be that you use Nx to develop your organizations UI design system component library (maybe using its [Storybook integration](/{{framework}}/storybook/overview)), which should be available also to your organizations’ apps that are not hosted within the same monorepo. + +A normal Nx library - let’s call it "workspace library" - is not made for building or publishing. Rather it only includes common lint and test targets in its `angular.json` or `workspace.json`. These libraries are directly referenced from one of the monorepo’s applications and built together with them. + +Keep in mind that the `--publishable` flag does not enable automatic publishing. Rather it adds to your Nx workspace library a builder target that **compiles** and **bundles** your app. The resulting artifact will be ready to be published to some registry (e.g. [npm](https://npmjs.com/)). By having that builder, you can invoke the build via a command like: `nx build mylib` (where "mylib" is the name of the lib) which will then produce an optimized bundle in the `dist/mylib` folder. Nx [also analyzes](/{{framework}}/angular/package#updatebuildableprojectdepsinpackagejson) the library’s dependencies and automatically compiles the dependencies in the resulting `package.json` file. + +One particularity when generating a library with `--publishable` is that it requires you to also provide an `--importPath`. Your import path is the actual scope of your distributable package (e.g.: `@myorg/mylib`) - which needs to be a [valid npm package name](https://docs.npmjs.com/files/package.json#name). + +To publish the library (for example to npm) you can run the CLI command: `npm publish` from the artifact located in the `dist` directory. Setting up some automated script in Nx’s `tools` folder may also come in handy. + +For more details on the mechanics, remember that Nx is an open source project, so you can see the actual impact of the generator by looking at the source code (the best starting point is probably `packages//src/generators/library/library.ts`). + +## Buildable libraries + +Buildable libraries are similar to "publishable libraries" described above. Their scope however is not to distribute or publish them to some external registry. Thus they might not be optimized for bundling and distribution. + +Buildable libraries are mostly used for producing some pre-compiled output that can be directly referenced from an Nx workspace application without the need to again compile it. A typical scenario is to leverage Nx’s [incremental building](/{{framework}}/ci/incremental-builds) capabilities. + +For more details on the mechanics, remember that Nx is an open source project, so you can see the actual impact of the generator by looking at the source code (the best starting point is probably `packages//src/generators/library/library.ts`). diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/creating-libraries.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/creating-libraries.md new file mode 100644 index 0000000000..aa5cf178dc --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/creating-libraries.md @@ -0,0 +1,33 @@ +# Creating Libraries + +Like a lot of decisions in programming, deciding to make a new Nx library or not is all about trade-offs. Each organization will decide on their own conventions, but here are some trade-offs to bear in mind as you have the conversation. + +## Should I Make a New Library? + +There are three main benefits to breaking your code up into more libraries. + +### 1. Faster Commands + +The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected --target=test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently. + +### 2. Visualizing Architecture + +The `nx dep-graph` command generates a graph of how apps and libraries depend on each other. If most of your code lives in a few giant libraries, this visualization doesn't provide much value. + +### 3. Enforcing Constraints + +You can enforce constraints on how different types of libraries depend on each other [using tags](/{{framework}}/structure/monorepo-tags). Following pre-determined conventions on what kind of code can go in different types of libraries allows your tagging system to enforce good architectural patterns. + +Also, each library defines its own API, which allows for encapsulating logic that other parts of codebase can not access. You can even use a [CODEOWNERS file](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners) to assign ownership of a certain library to a user or team. + +## Should I Add to an Existing Library? + +Limiting the number of libraries by keeping code in an existing library also has benefits. + +### 1. Consolidating Code + +Related code should be close together. If a developer can accomplish a task without moving between multiple different folders, it helps them work faster and make less mistakes. Every new library adds some folders and configuration files that are not directly contributing to business value. Nx helps reduce the cost of adding a new library, but it isn't zero. + +### 2. Removing Constraints + +Especially for rapidly evolving code, the standard architectural constraints may just get in the way of experimentation and exploration. It may be worthwhile to develop for a while in a single library in order to allow a real architecture to emerge and then refactoring into multiple libraries once the pace of change has slowed down. diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/grouping-libraries.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/grouping-libraries.md new file mode 100644 index 0000000000..6a370828a8 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/grouping-libraries.md @@ -0,0 +1,65 @@ +# Grouping Libraries + +Libraries should be grouped by _scope_. A library's scope is either application to which it belongs or (for larger applications) a section within that application. + +## Move Generator + +Don't be too anxious about choosing the exact right folder structure from the beginning. Libraries can be moved or renamed using the [`@nrwl/workspace:move` generator](/{{framework}}/workspace/move). + +For instance, if a library under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this: + +```bash +nx g move --project booking-some-library shared/some-library +``` + +## Remove Generator + +Similarly, if you no longer need a library, you can remove it with the [`@nrwl/workspace:remove` generator](/{{framework}}/workspace/remove). + +```bash +nx g remove booking-some-library +``` + +## Example Workspace + +Let's use Nrwl Airlines as an example organization. This organization has two apps, `booking` and `check-in`. In the Nx workspace, libraries related to `booking` are grouped under a `libs/booking` folder, libraries related to `check-in` are grouped under a `libs/check-in` folder and libraries used in both applications are placed in `libs/shared`. You can also have nested grouping folders, (i.e. `libs/shared/seatmap`). + +The purpose of these folders is to help with organizing by scope. We recommend grouping libraries together which are (usually) updated together. It helps minimize the amount of time a developer spends navigating the folder tree to find the right file. + +```txt +apps/ + booking/ + check-in/ +libs/ + booking/ <---- grouping folder + feature-shell/ <---- library + + check-in/ + feature-shell/ + + shared/ <---- grouping folder + data-access/ <---- library + + seatmap/ <---- grouping folder + data-access/ <---- library + feature-seatmap/ <---- library +``` + +## Sharing Libraries + +One of the main advantages of using a monorepo is that there is more visibility into code that can be reused across many different applications. Shared libraries are a great way to save developers time and effort by reusing a solution to a common problem. + +Let’s consider our reference monorepo. The `shared-data-access` library contains the code needed to communicate with the back-end (for example, the URL prefix). We know that this would be the same for all libs; therefore, we should place this in the shared lib and properly document it so that all projects can use it instead of writing their own versions. + +```txt + libs/ + booking/ + data-access/ <---- app-specific library + + shared/ + data-access/ <---- shared library + + seatmap/ + data-access/ <---- shared library + feature-seatmap/ <---- shared library +``` diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/library-types.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/library-types.md new file mode 100644 index 0000000000..8d4a9ab557 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/library-types.md @@ -0,0 +1,110 @@ +# Library Types + +There are many different types of libraries in a workspace. In order to maintain a certain sense of order, we recommend having a small number of types, such as the below four (4) types of libraries. + +**Feature libraries:** + +Developers should consider feature libraries as libraries that implement smart UI (with access to data sources) for specific business use cases or pages in an application. + +**UI libraries:** + +A UI library contains only presentational components (also called "dumb" components). + +**Data-access libraries:** + +A data-access library contains code for interacting with a back-end system. It also includes all the code related to state management. + +**Utility libraries:** + +A utility library contains low-level utilities used by many libraries and applications. + +--- + +## Feature Libraries + +**What is it?** + +A feature library contains a set of files that configure a business use case or a page in an application. Most of the components in such a library are smart components that interact with data sources. This type of library also contains most of the UI logic, form validation code, etc. Feature libraries are almost always app-specific and are often lazy-loaded. + +**Naming Convention** + +`feature` (if nested) or `feature-\*` (e.g., `feature-home`). + +**Dependency Constraints** + +A feature library can depend on any type of library. + +```treeview +libs/ +└── my-app/ + └── feature-home/ + └── src/ + ├── index.ts + └── lib/ +``` + +`feature-home` is the app-specific feature library (in this case, the "my-app" app). + +--- + +## UI Libraries + +**What is it?** + +A UI library is a collection of related presentational components. There are generally no services injected into these components (all of the data they need should come from Inputs). + +**Naming Convention** + +`ui` (if nested) or `ui-\*` (e.g., `ui-buttons`) + +**Dependency Constraints** + +A ui library can depend on ui and util libraries. + +--- + +## Data-access Libraries + +**What is it?** + +Data-access libraries contain code that function as client-side delegate layers to server tier APIs. + +All files related to state management also reside in a `data-access` folder (by convention, they can be grouped under a `+state` folder under `src/lib`). + +**Naming Convention** + +`data-access` (if nested) or `data-access-\*` (e.g. `data-access-seatmap`) + +**Dependency Constraints** + +A data-access library can depend on data-access and util libraries. + +--- + +## Utility Libraries + +**What is it?** + +A utility library contains low level code used by many libraries. Often there is no framework-specific code and the library is simply a collection of utilities or pure functions. + +**Naming Convention** + +`util` (if nested), or `util-\*` (e.g., `util-testing`) + +**Dependency Constraints** + +A utility library can depend only on utility libraries. + +An example ui lib module: **libs/shared/util-formatting** + +```typescript +export { formatDate, formatTime } from './src/format-date-fns'; +export { formatCurrency } from './src/format-currency'; +``` + +## Other Types + +You will probably come up with other library types that make sense for your organization. That's fine. Just keep a few things in mind: + +- Keep the number of library types low +- Clearly document what each type of library means diff --git a/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/structure/dependency-graph.md b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/structure/dependency-graph.md new file mode 100644 index 0000000000..93c2d98866 --- /dev/null +++ b/nx-dev/data-access-documents/src/data/11.4.0/shared/workspace/structure/dependency-graph.md @@ -0,0 +1,52 @@ +# Analyzing & Visualizing Workspaces + +To be able to support the monorepo-style development, the tools must know how different projects in your workspace depend on each other. Nx uses advanced code analysis to construct this dependency graph. And it gives you a way to explore it: + + + +## How the Dependency Graph is Built + +Nx creates a graph of all the dependencies between projects in your workspace using two sources of information: + +1. Typescript `import` statements referencing a particular project's path alias + + For instance, if a file in `my-app` has this code: + + ```typescript + import { something } from '@myorg/awesome-library'; + ``` + + Then `my-app` depends on `awesome-library` + +2. Manually created `implicitDependencies` in the `nx.json` file. [Full `implicitDependencies` documentation](/{{framework}}/getting-started/configuration#implicit-dependencies) + + If your `nx.json` has this content: + + ```json + { + "projects": { + "my-app": { + "tags": [], + "implicitDependencies": ["my-api"] + } + } + } + ``` + + Then `my-app` depends on `my-api` + +## Circular Dependencies + +A circular dependency is when a project transitively depends on itself. This can cause problems in the design of your software and also makes Nx's affected algorithm less effective. The lint rule, `nx-enforce-module-boundaries`, will produce an error if any circular dependencies are created and ensures that any `import` statements going across projects only `import` from the defined public apis in a project's root `index.ts` file. + +When migrating a new codebase into an nx workspace, you'll likely begin to uncover existing circular dependencies. Let's look at the simplest possible circular dependency, where `projectA` depends on `projectB` and vice versa. + +**To resolve circular dependencies:** + +First, identify the `import` statements causing the dependency. Search in the source folder of `projectA` for references to `@myorg/projectB` and search in the source folder of `projectB` for references to `@myorg/projectA`. + +Then there are three strategies you can use: + +1. Look for small pieces of code that can be moved from one project to the other. +2. Look for code that both libraries depend on and move that code into a new shared library. +3. Combine `projectA` and `projectB` into one library. diff --git a/nx-dev/data-access-documents/src/data/versions.json b/nx-dev/data-access-documents/src/data/versions.json new file mode 100644 index 0000000000..bc276301fd --- /dev/null +++ b/nx-dev/data-access-documents/src/data/versions.json @@ -0,0 +1,16 @@ +[ + { + "name": "Latest (v11.4.0)", + "id": "latest", + "release": "11.4.0", + "path": "11.4.0", + "default": true + }, + { + "name": "Previous (v10.4.13)", + "id": "previous", + "release": "10.4.13", + "path": "10.4.13", + "default": false + } +] diff --git a/nx-dev/data-access-documents/src/index.ts b/nx-dev/data-access-documents/src/index.ts new file mode 100644 index 0000000000..92b66dfce2 --- /dev/null +++ b/nx-dev/data-access-documents/src/index.ts @@ -0,0 +1,2 @@ +export * from './lib/documentation-api'; +export * from './lib/models'; diff --git a/nx-dev/data-access-documents/src/lib/documentation-api.spec.ts b/nx-dev/data-access-documents/src/lib/documentation-api.spec.ts new file mode 100644 index 0000000000..bf09e8d221 --- /dev/null +++ b/nx-dev/data-access-documents/src/lib/documentation-api.spec.ts @@ -0,0 +1,19 @@ +import { getDocument } from './documentation-api'; + +describe('getDocument', () => { + it('should retrieve documents that exist', () => { + const result = getDocument('latest', [ + 'react', + 'getting-started', + 'getting-started', + ]); + + expect(result.filePath).toBeTruthy(); + }); + + it('should throw error if segments do not match a file', () => { + expect(() => + getDocument('latest', ['this', 'does', 'not', 'exist']) + ).toThrow(); + }); +}); diff --git a/nx-dev/data-access-documents/src/lib/documentation-api.ts b/nx-dev/data-access-documents/src/lib/documentation-api.ts new file mode 100644 index 0000000000..153c703538 --- /dev/null +++ b/nx-dev/data-access-documents/src/lib/documentation-api.ts @@ -0,0 +1,79 @@ +import * as fs from 'fs'; +import { join } from 'path'; +import matter from 'gray-matter'; +import * as marked from 'marked'; +import { + getDocumentsMap, + getDocumentsRoot, + getVersions as _getVersions, +} from './utils'; +import { DocumentData, VersionData } from './models'; + +export function getDocument( + version: string, + _segments: string | string[] +): DocumentData { + const segments = Array.isArray(_segments) ? [..._segments] : [_segments]; + const docPath = getFilePath(version, segments); + const file = matter(fs.readFileSync(docPath, 'utf8')); + + return { + filePath: docPath, + data: file.data, + content: marked.parse(file.content), + excerpt: file.excerpt, + }; +} + +export function getFilePath(version: string, segments: string[]): string { + let items = getDocumentsMap(version); + let found; + for (const segment of segments) { + found = items.find((item) => item.id === segment); + if (found) { + items = found.itemList; + } else { + throw new Error( + `Cannot find document matching segments: ${segments.join(',')}` + ); + } + } + if (!found.file) { + throw new Error( + `Cannot find document matching segments: ${segments.join(',')}` + ); + } + return join(getDocumentsRoot(version), `${found.file}.md`); +} + +export function getAllDocumentsPaths(version: string) { + const paths = []; + + function recur(curr, acc) { + if (curr.file) { + paths.push({ + params: { + version, + flavor: acc[0], + segments: acc.slice(2).concat(curr.id), + }, + }); + return; + } + if (curr.itemList) { + curr.itemList.forEach((ii) => { + recur(ii, [...acc, curr.id]); + }); + } + } + + getDocumentsMap(version).forEach((item) => { + recur(item, [item.id]); + }); + + return paths; +} + +export function getVersions(): VersionData[] { + return _getVersions(); +} diff --git a/nx-dev/data-access-documents/src/lib/models.ts b/nx-dev/data-access-documents/src/lib/models.ts new file mode 100644 index 0000000000..32c0c7b7fc --- /dev/null +++ b/nx-dev/data-access-documents/src/lib/models.ts @@ -0,0 +1,21 @@ +export interface DocumentData { + filePath: string; + data: { [key: string]: any }; + content: string; + excerpt?: string; +} + +export interface VersionData { + name: string; + id: string; + release: string; + path: string; + default: boolean; +} + +export interface Item { + name: string; + id: string; + file?: string; + itemList?: Item[]; +} diff --git a/nx-dev/data-access-documents/src/lib/utils.spec.ts b/nx-dev/data-access-documents/src/lib/utils.spec.ts new file mode 100644 index 0000000000..a51c9d9b28 --- /dev/null +++ b/nx-dev/data-access-documents/src/lib/utils.spec.ts @@ -0,0 +1,28 @@ +import { getDocumentsRoot, getVersions } from './utils'; + +describe('getDocumentsPath', () => { + it('should support preview', () => { + expect(getDocumentsRoot('preview')).toMatch('docs'); + }); + + it('should support latest', () => { + expect(getDocumentsRoot('latest')).toMatch( + /data-access-documents\/src\/data\/\d+\.\d+\.\d+/ + ); + }); + + it('should support previous', () => { + expect(getDocumentsRoot('previous')).toMatch( + /data-access-documents\/src\/data\/\d+\.\d+\.\d+/ + ); + }); +}); + +describe('getVersions', () => { + it('should return versions data', () => { + expect(getVersions()).toEqual([ + expect.objectContaining({ id: 'latest' }), + expect.objectContaining({ id: 'previous' }), + ]); + }); +}); diff --git a/nx-dev/data-access-documents/src/lib/utils.ts b/nx-dev/data-access-documents/src/lib/utils.ts new file mode 100644 index 0000000000..cce589eb45 --- /dev/null +++ b/nx-dev/data-access-documents/src/lib/utils.ts @@ -0,0 +1,43 @@ +import { readJsonFile } from '@nrwl/workspace'; +import { join } from 'path'; +import { appRootPath } from '@nrwl/workspace/src/utilities/app-root'; + +import { Item, VersionData } from './models'; +import versionsData from '../data/versions.json'; + +const dataRoot = join(appRootPath, 'nx-dev/data-access-documents/src/data'); +const previewRoot = join(appRootPath, 'docs'); + +const mapCache = new Map(); +export function getDocumentsMap(version: string) { + try { + let map = mapCache.get(version); + if (!map) { + map = readJsonFile(join(getDocumentsRoot(version), 'map.json')); + mapCache.set(version, map); + } + return map; + } catch { + throw new Error(`Cannot find map.json for ${version}`); + } +} + +export function getDocumentsRoot(version: string): string { + if (version === 'preview') { + return previewRoot; + } + + if (version === 'latest' || version === 'previous') { + return join(dataRoot, versionsData.find((x) => x.id === version).path); + } + + throw new Error(`Cannot find root for ${version}`); +} + +let versions: VersionData[]; +export function getVersions(): VersionData[] { + if (!versions) { + versions = readJsonFile(join(dataRoot, 'versions.json')); + } + return versions; +} diff --git a/nx-dev/data-access-documents/tsconfig.json b/nx-dev/data-access-documents/tsconfig.json new file mode 100644 index 0000000000..62ebbd9464 --- /dev/null +++ b/nx-dev/data-access-documents/tsconfig.json @@ -0,0 +1,13 @@ +{ + "extends": "../../tsconfig.base.json", + "files": [], + "include": [], + "references": [ + { + "path": "./tsconfig.lib.json" + }, + { + "path": "./tsconfig.spec.json" + } + ] +} diff --git a/nx-dev/data-access-documents/tsconfig.lib.json b/nx-dev/data-access-documents/tsconfig.lib.json new file mode 100644 index 0000000000..7bce65e5cf --- /dev/null +++ b/nx-dev/data-access-documents/tsconfig.lib.json @@ -0,0 +1,12 @@ +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "allowSyntheticDefaultImports": true, + "esModuleInterop": true, + "resolveJsonModule": true, + "outDir": "../../../dist/out-tsc", + "types": [] + }, + "include": ["**/*.ts"], + "exclude": ["**/*.spec.ts"] +} diff --git a/nx-dev/data-access-documents/tsconfig.spec.json b/nx-dev/data-access-documents/tsconfig.spec.json new file mode 100644 index 0000000000..3706777f62 --- /dev/null +++ b/nx-dev/data-access-documents/tsconfig.spec.json @@ -0,0 +1,18 @@ +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "allowSyntheticDefaultImports": true, + "esModuleInterop": true, + "resolveJsonModule": true, + "outDir": "../../../dist/out-tsc", + "module": "commonjs", + "types": ["jest", "node"] + }, + "include": [ + "**/*.spec.ts", + "**/*.spec.tsx", + "**/*.spec.js", + "**/*.spec.jsx", + "**/*.d.ts" + ] +} diff --git a/nx-dev/feature-doc-viewer/.babelrc b/nx-dev/feature-doc-viewer/.babelrc new file mode 100644 index 0000000000..09d67939cc --- /dev/null +++ b/nx-dev/feature-doc-viewer/.babelrc @@ -0,0 +1,4 @@ +{ + "presets": ["@nrwl/react/babel"], + "plugins": [] +} diff --git a/nx-dev/feature-doc-viewer/.eslintrc.json b/nx-dev/feature-doc-viewer/.eslintrc.json new file mode 100644 index 0000000000..ce08cad8a7 --- /dev/null +++ b/nx-dev/feature-doc-viewer/.eslintrc.json @@ -0,0 +1,21 @@ +{ + "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"], + "ignorePatterns": ["!**/*"], + "overrides": [ + { + "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], + "parserOptions": { + "project": ["nx-dev/feature-doc-viewer/tsconfig.*?.json"] + }, + "rules": {} + }, + { + "files": ["*.ts", "*.tsx"], + "rules": {} + }, + { + "files": ["*.js", "*.jsx"], + "rules": {} + } + ] +} diff --git a/nx-dev/feature-doc-viewer/README.md b/nx-dev/feature-doc-viewer/README.md new file mode 100644 index 0000000000..fb159c010c --- /dev/null +++ b/nx-dev/feature-doc-viewer/README.md @@ -0,0 +1,7 @@ +# documentation-feature-doc-viewer + +This library was generated with [Nx](https://nx.dev). + +## Running unit tests + +Run `nx test documentation-feature-doc-viewer` to execute the unit tests via [Jest](https://jestjs.io). diff --git a/nx-dev/feature-doc-viewer/jest.config.js b/nx-dev/feature-doc-viewer/jest.config.js new file mode 100644 index 0000000000..f738f6075d --- /dev/null +++ b/nx-dev/feature-doc-viewer/jest.config.js @@ -0,0 +1,10 @@ +const nxPreset = require('@nrwl/jest/preset'); +module.exports = { + ...nxPreset, + displayName: 'nx-dev-feature-doc-viewer', + transform: { + '^.+\\.[tj]sx?$': 'babel-jest', + }, + moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx'], + coverageDirectory: '../../coverage/nx-dev/feature-doc-viewer', +}; diff --git a/nx-dev/feature-doc-viewer/src/index.ts b/nx-dev/feature-doc-viewer/src/index.ts new file mode 100644 index 0000000000..36f4daaa68 --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/index.ts @@ -0,0 +1 @@ +export * from './lib/doc-viewer'; diff --git a/nx-dev/feature-doc-viewer/src/lib/content.spec.tsx b/nx-dev/feature-doc-viewer/src/lib/content.spec.tsx new file mode 100644 index 0000000000..236c7822cc --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/content.spec.tsx @@ -0,0 +1,11 @@ +import React from 'react'; +import { render } from '@testing-library/react'; + +import Content from './content'; + +describe('Content', () => { + it('should render successfully', () => { + const { baseElement } = render(); + expect(baseElement).toBeTruthy(); + }); +}); diff --git a/nx-dev/feature-doc-viewer/src/lib/content.tsx b/nx-dev/feature-doc-viewer/src/lib/content.tsx new file mode 100644 index 0000000000..30559c458b --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/content.tsx @@ -0,0 +1,19 @@ +import React from 'react'; + +/* eslint-disable-next-line */ +export interface ContentProps { + data: any; +} + +export function Content(props: ContentProps) { + return ( +
+
+
+ ); +} + +export default Content; diff --git a/nx-dev/feature-doc-viewer/src/lib/doc-viewer.spec.tsx b/nx-dev/feature-doc-viewer/src/lib/doc-viewer.spec.tsx new file mode 100644 index 0000000000..75571a9a84 --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/doc-viewer.spec.tsx @@ -0,0 +1,11 @@ +import React from 'react'; +import { render } from '@testing-library/react'; + +import DocViewer from './doc-viewer'; + +describe('DocViewer', () => { + it('should render successfully', () => { + const { baseElement } = render(); + expect(baseElement).toBeTruthy(); + }); +}); diff --git a/nx-dev/feature-doc-viewer/src/lib/doc-viewer.tsx b/nx-dev/feature-doc-viewer/src/lib/doc-viewer.tsx new file mode 100644 index 0000000000..ea7b1aaa88 --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/doc-viewer.tsx @@ -0,0 +1,36 @@ +import React from 'react'; +import Content from './content'; +import Sidebar from './sidebar'; +import Toc from './toc'; + +/* eslint-disable-next-line */ +export interface DocumentationFeatureDocViewerProps { + sidebar: any; + content: any; + toc: any; +} + +export function DocViewer(props: DocumentationFeatureDocViewerProps) { + return ( +
+
+ +
+
+ +
+
+ +
+
+
+
+
+
+ ); +} + +export default DocViewer; diff --git a/nx-dev/feature-doc-viewer/src/lib/sidebar.spec.tsx b/nx-dev/feature-doc-viewer/src/lib/sidebar.spec.tsx new file mode 100644 index 0000000000..54b0c4baf7 --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/sidebar.spec.tsx @@ -0,0 +1,11 @@ +import React from 'react'; +import { render } from '@testing-library/react'; + +import Sidebar from './sidebar'; + +describe('Sidebar', () => { + it('should render successfully', () => { + const { baseElement } = render(); + expect(baseElement).toBeTruthy(); + }); +}); diff --git a/nx-dev/feature-doc-viewer/src/lib/sidebar.tsx b/nx-dev/feature-doc-viewer/src/lib/sidebar.tsx new file mode 100644 index 0000000000..77f2af742f --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/sidebar.tsx @@ -0,0 +1,54 @@ +import React from 'react'; + +/* eslint-disable-next-line */ +export interface SidebarProps {} + +export function Sidebar(props: SidebarProps) { + return ( + + ); +} + +export default Sidebar; diff --git a/nx-dev/feature-doc-viewer/src/lib/toc.spec.tsx b/nx-dev/feature-doc-viewer/src/lib/toc.spec.tsx new file mode 100644 index 0000000000..27584108ea --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/toc.spec.tsx @@ -0,0 +1,11 @@ +import React from 'react'; +import { render } from '@testing-library/react'; + +import Toc from './toc'; + +describe('Toc', () => { + it('should render successfully', () => { + const { baseElement } = render(); + expect(baseElement).toBeTruthy(); + }); +}); diff --git a/nx-dev/feature-doc-viewer/src/lib/toc.tsx b/nx-dev/feature-doc-viewer/src/lib/toc.tsx new file mode 100644 index 0000000000..bb0e668020 --- /dev/null +++ b/nx-dev/feature-doc-viewer/src/lib/toc.tsx @@ -0,0 +1,34 @@ +import React from 'react'; + +/* eslint-disable-next-line */ +export interface TocProps {} + +export function Toc(props: TocProps) { + return ( +
+
+ On this page +
+ +
+ ); +} + +export default Toc; diff --git a/nx-dev/feature-doc-viewer/tsconfig.json b/nx-dev/feature-doc-viewer/tsconfig.json new file mode 100644 index 0000000000..d8eb687121 --- /dev/null +++ b/nx-dev/feature-doc-viewer/tsconfig.json @@ -0,0 +1,19 @@ +{ + "extends": "../../tsconfig.base.json", + "compilerOptions": { + "jsx": "react", + "allowJs": true, + "esModuleInterop": true, + "allowSyntheticDefaultImports": true + }, + "files": [], + "include": [], + "references": [ + { + "path": "./tsconfig.lib.json" + }, + { + "path": "./tsconfig.spec.json" + } + ] +} diff --git a/nx-dev/feature-doc-viewer/tsconfig.lib.json b/nx-dev/feature-doc-viewer/tsconfig.lib.json new file mode 100644 index 0000000000..b560bc4dec --- /dev/null +++ b/nx-dev/feature-doc-viewer/tsconfig.lib.json @@ -0,0 +1,13 @@ +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../../dist/out-tsc", + "types": ["node"] + }, + "files": [ + "../../../node_modules/@nrwl/react/typings/cssmodule.d.ts", + "../../../node_modules/@nrwl/react/typings/image.d.ts" + ], + "exclude": ["**/*.spec.ts", "**/*.spec.tsx"], + "include": ["**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx"] +} diff --git a/nx-dev/feature-doc-viewer/tsconfig.spec.json b/nx-dev/feature-doc-viewer/tsconfig.spec.json new file mode 100644 index 0000000000..1798b378a9 --- /dev/null +++ b/nx-dev/feature-doc-viewer/tsconfig.spec.json @@ -0,0 +1,15 @@ +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "outDir": "../../../dist/out-tsc", + "module": "commonjs", + "types": ["jest", "node"] + }, + "include": [ + "**/*.spec.ts", + "**/*.spec.tsx", + "**/*.spec.js", + "**/*.spec.jsx", + "**/*.d.ts" + ] +} diff --git a/nx-dev/nx-dev-e2e/.eslintrc.json b/nx-dev/nx-dev-e2e/.eslintrc.json new file mode 100644 index 0000000000..595f51e407 --- /dev/null +++ b/nx-dev/nx-dev-e2e/.eslintrc.json @@ -0,0 +1,14 @@ +{ + "extends": ["plugin:cypress/recommended", "../../.eslintrc.json"], + "ignorePatterns": ["!**/*"], + "rules": {}, + "overrides": [ + { + "files": ["src/plugins/index.js"], + "rules": { + "@typescript-eslint/no-var-requires": "off", + "no-undef": "off" + } + } + ] +} diff --git a/nx-dev/nx-dev-e2e/cypress.json b/nx-dev/nx-dev-e2e/cypress.json new file mode 100644 index 0000000000..941faa4cf8 --- /dev/null +++ b/nx-dev/nx-dev-e2e/cypress.json @@ -0,0 +1,12 @@ +{ + "fileServerFolder": ".", + "fixturesFolder": "./src/fixtures", + "integrationFolder": "./src/integration", + "modifyObstructiveCode": false, + "pluginsFile": "./src/plugins/index", + "supportFile": "./src/support/index.ts", + "video": true, + "videosFolder": "../../dist/cypress/apps/documentation-e2e/videos", + "screenshotsFolder": "../../dist/cypress/apps/documentation-e2e/screenshots", + "chromeWebSecurity": false +} diff --git a/nx-dev/nx-dev-e2e/src/fixtures/example.json b/nx-dev/nx-dev-e2e/src/fixtures/example.json new file mode 100644 index 0000000000..294cbed6ce --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/fixtures/example.json @@ -0,0 +1,4 @@ +{ + "name": "Using fixtures to represent data", + "email": "hello@cypress.io" +} diff --git a/nx-dev/nx-dev-e2e/src/integration/app.spec.ts b/nx-dev/nx-dev-e2e/src/integration/app.spec.ts new file mode 100644 index 0000000000..63ea8befe7 --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/integration/app.spec.ts @@ -0,0 +1,13 @@ +import { getGreeting } from '../support/app.po'; + +describe('documentation', () => { + beforeEach(() => cy.visit('/')); + + it('should display welcome message', () => { + // Custom command example, see `../support/commands.ts` file + cy.login('my-email@something.com', 'myPassword'); + + // Function helper example, see `../support/app.po.ts` file + getGreeting().contains('Welcome to documentation!'); + }); +}); diff --git a/nx-dev/nx-dev-e2e/src/plugins/index.js b/nx-dev/nx-dev-e2e/src/plugins/index.js new file mode 100644 index 0000000000..9067e75a25 --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/plugins/index.js @@ -0,0 +1,22 @@ +// *********************************************************** +// This example plugins/index.js can be used to load plugins +// +// You can change the location of this file or turn off loading +// the plugins file with the 'pluginsFile' configuration option. +// +// You can read more here: +// https://on.cypress.io/plugins-guide +// *********************************************************** + +// This function is called when a project is opened or re-opened (e.g. due to +// the project's config changing) + +const { preprocessTypescript } = require('@nrwl/cypress/plugins/preprocessor'); + +module.exports = (on, config) => { + // `on` is used to hook into various events Cypress emits + // `config` is the resolved Cypress config + + // Preprocess Typescript file using Nx helper + on('file:preprocessor', preprocessTypescript(config)); +}; diff --git a/nx-dev/nx-dev-e2e/src/support/app.po.ts b/nx-dev/nx-dev-e2e/src/support/app.po.ts new file mode 100644 index 0000000000..3293424696 --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/support/app.po.ts @@ -0,0 +1 @@ +export const getGreeting = () => cy.get('h1'); diff --git a/nx-dev/nx-dev-e2e/src/support/commands.ts b/nx-dev/nx-dev-e2e/src/support/commands.ts new file mode 100644 index 0000000000..310f1fa0e0 --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/support/commands.ts @@ -0,0 +1,33 @@ +// *********************************************** +// This example commands.js shows you how to +// create various custom commands and overwrite +// existing commands. +// +// For more comprehensive examples of custom +// commands please read more here: +// https://on.cypress.io/custom-commands +// *********************************************** + +// eslint-disable-next-line @typescript-eslint/no-namespace +declare namespace Cypress { + // eslint-disable-next-line @typescript-eslint/no-unused-vars + interface Chainable { + login(email: string, password: string): void; + } +} +// +// -- This is a parent command -- +Cypress.Commands.add('login', (email, password) => { + console.log('Custom command example: Login', email, password); +}); +// +// -- This is a child command -- +// Cypress.Commands.add("drag", { prevSubject: 'element'}, (subject, options) => { ... }) +// +// +// -- This is a dual command -- +// Cypress.Commands.add("dismiss", { prevSubject: 'optional'}, (subject, options) => { ... }) +// +// +// -- This will overwrite an existing command -- +// Cypress.Commands.overwrite("visit", (originalFn, url, options) => { ... }) diff --git a/nx-dev/nx-dev-e2e/src/support/index.ts b/nx-dev/nx-dev-e2e/src/support/index.ts new file mode 100644 index 0000000000..3d469a6b6c --- /dev/null +++ b/nx-dev/nx-dev-e2e/src/support/index.ts @@ -0,0 +1,17 @@ +// *********************************************************** +// This example support/index.js is processed and +// loaded automatically before your test files. +// +// This is a great place to put global configuration and +// behavior that modifies Cypress. +// +// You can change the location of this file or turn off +// automatically serving support files with the +// 'supportFile' configuration option. +// +// You can read more here: +// https://on.cypress.io/configuration +// *********************************************************** + +// Import commands.js using ES2015 syntax: +import './commands'; diff --git a/nx-dev/nx-dev-e2e/tsconfig.e2e.json b/nx-dev/nx-dev-e2e/tsconfig.e2e.json new file mode 100644 index 0000000000..9dc3660a79 --- /dev/null +++ b/nx-dev/nx-dev-e2e/tsconfig.e2e.json @@ -0,0 +1,10 @@ +{ + "extends": "./tsconfig.json", + "compilerOptions": { + "sourceMap": false, + "outDir": "../../dist/out-tsc", + "allowJs": true, + "types": ["cypress", "node"] + }, + "include": ["src/**/*.ts", "src/**/*.js"] +} diff --git a/nx-dev/nx-dev-e2e/tsconfig.json b/nx-dev/nx-dev-e2e/tsconfig.json new file mode 100644 index 0000000000..08841a7f56 --- /dev/null +++ b/nx-dev/nx-dev-e2e/tsconfig.json @@ -0,0 +1,10 @@ +{ + "extends": "../../tsconfig.base.json", + "files": [], + "include": [], + "references": [ + { + "path": "./tsconfig.e2e.json" + } + ] +} diff --git a/nx-dev/nx-dev/.babelrc b/nx-dev/nx-dev/.babelrc new file mode 100644 index 0000000000..9fcef0394f --- /dev/null +++ b/nx-dev/nx-dev/.babelrc @@ -0,0 +1,4 @@ +{ + "presets": ["next/babel"], + "plugins": [] +} diff --git a/nx-dev/nx-dev/.eslintrc.json b/nx-dev/nx-dev/.eslintrc.json new file mode 100644 index 0000000000..b8b29b78f4 --- /dev/null +++ b/nx-dev/nx-dev/.eslintrc.json @@ -0,0 +1,4 @@ +{ + "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"], + "ignorePatterns": ["!**/*"] +} diff --git a/nx-dev/nx-dev/index.d.ts b/nx-dev/nx-dev/index.d.ts new file mode 100644 index 0000000000..7ba08fa17c --- /dev/null +++ b/nx-dev/nx-dev/index.d.ts @@ -0,0 +1,6 @@ +/* eslint-disable @typescript-eslint/no-explicit-any */ +declare module '*.svg' { + const content: any; + export const ReactComponent: any; + export default content; +} diff --git a/nx-dev/nx-dev/jest.config.js b/nx-dev/nx-dev/jest.config.js new file mode 100644 index 0000000000..cba59d7606 --- /dev/null +++ b/nx-dev/nx-dev/jest.config.js @@ -0,0 +1,11 @@ +const nxPreset = require('@nrwl/jest/preset'); +module.exports = { + ...nxPreset, + displayName: 'nx-dev', + transform: { + '^(?!.*\\.(js|jsx|ts|tsx|css|json)$)': '@nrwl/react/plugins/jest', + '^.+\\.[tj]sx?$': 'babel-jest', + }, + moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx'], + coverageDirectory: '../../coverage/nx-dev/nx-dev', +}; diff --git a/nx-dev/nx-dev/next-env.d.ts b/nx-dev/nx-dev/next-env.d.ts new file mode 100644 index 0000000000..7b7aa2c772 --- /dev/null +++ b/nx-dev/nx-dev/next-env.d.ts @@ -0,0 +1,2 @@ +/// +/// diff --git a/nx-dev/nx-dev/next.config.js b/nx-dev/nx-dev/next.config.js new file mode 100644 index 0000000000..4fab0da62d --- /dev/null +++ b/nx-dev/nx-dev/next.config.js @@ -0,0 +1,4 @@ +// eslint-disable-next-line @typescript-eslint/no-var-requires +const withNx = require('@nrwl/next/plugins/with-nx'); + +module.exports = withNx({}); diff --git a/nx-dev/nx-dev/pages/[version]/[flavor]/[...segments].tsx b/nx-dev/nx-dev/pages/[version]/[flavor]/[...segments].tsx new file mode 100644 index 0000000000..faf4eb3264 --- /dev/null +++ b/nx-dev/nx-dev/pages/[version]/[flavor]/[...segments].tsx @@ -0,0 +1,52 @@ +import * as React from 'react'; +import { + getDocument, + getAllDocumentsPaths, + DocumentData, + getVersions, + VersionData, +} from '@nrwl/nx-dev/data-access-documents'; +import { DocViewer } from '@nrwl/nx-dev/feature-doc-viewer'; + +interface DocumentationProps { + document: DocumentData; + versions: VersionData[]; +} + +interface DocumentationParams { + params: { version: string; flavor: string; segments: string | string[] }; +} + +export function Documentation(props: DocumentationProps) { + return ( + + ); +} + +export async function getStaticProps({ params }: DocumentationParams) { + return { + props: { + versions: getVersions(), + document: getDocument(params.version, [ + params.flavor, + ...params.segments, + ]), + }, + }; +} + +export async function getStaticPaths(props) { + const versions = ['preview'].concat(getVersions().map((x) => x.id)); + + const allPaths = versions.reduce((acc, v) => { + acc.push(...getAllDocumentsPaths(v)); + return acc; + }, []); + + return { + paths: allPaths, + fallback: false, + }; +} + +export default Documentation; diff --git a/nx-dev/nx-dev/pages/_app.tsx b/nx-dev/nx-dev/pages/_app.tsx new file mode 100644 index 0000000000..369609fc7d --- /dev/null +++ b/nx-dev/nx-dev/pages/_app.tsx @@ -0,0 +1,39 @@ +import React from 'react'; +import { AppProps } from 'next/app'; +import Head from 'next/head'; +import { Header, Footer } from '@nrwl/nx-dev/ui-common'; +import './styles.css'; + +export default function CustomApp({ Component, pageProps }: AppProps) { + return ( + <> + + {/* ONLY TEMPORARY */} + + + + + Welcome to documentation! + +
+
+
+ +
+
+