miel.truyen/nx
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs(angular): cleanup some minor issues in docs (#6267)

Browse Source
This commit is contained in:
Colum Ferry 2021-07-08 09:12:09 +01:00 committed by GitHub
parent 549e18b234
commit 757e02d75c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 32 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/shared/migration/overview.md
View File

@ -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)

16
docs/shared/migration/preserving-git-histories.md
View File

@ -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 <repository url>
git remote add my-standalone-app <repository url>
```
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!

16
nx-dev/nx-dev/public/documentation/latest/shared/migration/preserving-git-histories.md
View File

@ -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 <repository url>
git remote add my-standalone-app <repository url>
```
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!

18
nx-dev/nx-dev/public/documentation/previous/shared/migration/preserving-git-histories.md
View File

@ -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 <repository url>
git remote add my-standalone-app <repository url>
```
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!