From 757e02d75c7b8f277ebaddfa7d17e43ba1b42a77 Mon Sep 17 00:00:00 2001 From: Colum Ferry Date: Thu, 8 Jul 2021 09:12:09 +0100 Subject: [PATCH] docs(angular): cleanup some minor issues in docs (#6267) --- docs/shared/migration/overview.md | 12 +++++++----- .../migration/preserving-git-histories.md | 16 ++++++++-------- .../migration/preserving-git-histories.md | 16 ++++++++-------- .../migration/preserving-git-histories.md | 18 +++++++++--------- 4 files changed, 32 insertions(+), 30 deletions(-) diff --git a/docs/shared/migration/overview.md b/docs/shared/migration/overview.md index 24bd063636..f950468b76 100644 --- a/docs/shared/migration/overview.md +++ b/docs/shared/migration/overview.md @@ -64,7 +64,7 @@ You may also find it useful to use the [Nx Console](/{{framework}}/getting-start ### 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. +Your workspace contains different configuration files for the tools you’ll need to develop, such as linters, bundlers, and executors. 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. @@ -86,7 +86,7 @@ There are two major steps to migrating your application: migrating your dependen 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/) +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 @@ -96,7 +96,8 @@ If your code is all in a single app, you can copy it into the application’s fo Now that your code is present, it’s time to tackle building and testing it. -Local build and serve +### 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 @@ -135,7 +136,7 @@ All of the configuration for your e2e tests should be in this directory. ### 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. +Nx uses ESLint for linting. Nx also has its own lint process to make sure your Nx configuration is valid. To run the `lint` task for your workspace @@ -195,7 +196,8 @@ 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 +### 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/docs/shared/migration/preserving-git-histories.md b/docs/shared/migration/preserving-git-histories.md index 37f16ece68..9cdf9a9b8c 100644 --- a/docs/shared/migration/preserving-git-histories.md +++ b/docs/shared/migration/preserving-git-histories.md @@ -1,25 +1,25 @@ -# Preserving Git Histories When Migrating Other Projects to Your Nx Workspace +# 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. +The nature of a monorepo is to swallow up standalone projects as your organization buys into the benefits of a monorepo 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. +As your monorepo 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 +## 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 +git remote add my-standalone-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 +git merge my-standalone-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`. @@ -32,8 +32,8 @@ For your `package-lock.json` or `yarn.lock`, it's likely best to remove those en For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.base.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. -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. +Note that for these files, the file history of the standalone 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! +If your standalone project was not an Nx workspace, it's likely that your migration work will also entail moving 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/nx-dev/public/documentation/latest/shared/migration/preserving-git-histories.md b/nx-dev/nx-dev/public/documentation/latest/shared/migration/preserving-git-histories.md index ce068b52cb..9cdf9a9b8c 100644 --- a/nx-dev/nx-dev/public/documentation/latest/shared/migration/preserving-git-histories.md +++ b/nx-dev/nx-dev/public/documentation/latest/shared/migration/preserving-git-histories.md @@ -1,25 +1,25 @@ -# Preserving Git Histories When Migrating Other Projects to Your Nx Workspace +# 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. +The nature of a monorepo is to swallow up standalone projects as your organization buys into the benefits of a monorepo 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. +As your monorepo 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 +## 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 +git remote add my-standalone-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 +git merge my-standalone-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`. @@ -32,8 +32,8 @@ For your `package-lock.json` or `yarn.lock`, it's likely best to remove those en For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.base.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. -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. +Note that for these files, the file history of the standalone 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 [Migration Overview page](/{{framework}}/migration/overview), 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! +If your standalone project was not an Nx workspace, it's likely that your migration work will also entail moving 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/nx-dev/public/documentation/previous/shared/migration/preserving-git-histories.md b/nx-dev/nx-dev/public/documentation/previous/shared/migration/preserving-git-histories.md index 5ff6876083..9cdf9a9b8c 100644 --- a/nx-dev/nx-dev/public/documentation/previous/shared/migration/preserving-git-histories.md +++ b/nx-dev/nx-dev/public/documentation/previous/shared/migration/preserving-git-histories.md @@ -1,25 +1,25 @@ -# Preserving Git Histories When Migrating Other Projects to Your Nx Workspace +# 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. +The nature of a monorepo is to swallow up standalone projects as your organization buys into the benefits of a monorepo 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. +As your monorepo 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 +## 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 +git remote add my-standalone-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 +git merge my-standalone-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`. @@ -30,10 +30,10 @@ At this point, it is very likely that you'll have merge conflicts in your root f For your `package-lock.json` or `yarn.lock`, it's likely best to remove those entirely and allow a new lock file to be generated by installing when the merge is complete. -For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. +For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.base.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. -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. +Note that for these files, the file history of the standalone 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! +If your standalone project was not an Nx workspace, it's likely that your migration work will also entail moving 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!