docs(core): code sharing concept guide (#14852)

docs/generated/manifests/menus.json

@@ -1026,6 +1026,14 @@
             "children": [],
             "disableCollapsible": false
           },
+          {
+            "name": "Code Sharing",
+            "path": "/more-concepts/code-sharing",
+            "id": "code-sharing",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
           {
             "name": "Using Nx at Enterprises",
             "path": "/more-concepts/monorepo-nx-enterprise",
@@ -1173,6 +1181,14 @@
         "children": [],
         "disableCollapsible": false
       },
+      {
+        "name": "Code Sharing",
+        "path": "/more-concepts/code-sharing",
+        "id": "code-sharing",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
       {
         "name": "Using Nx at Enterprises",
         "path": "/more-concepts/monorepo-nx-enterprise",

docs/generated/manifests/nx.json

@@ -1275,6 +1275,16 @@
         "path": "/more-concepts/dependency-management",
         "tags": []
       },
+      {
+        "id": "code-sharing",
+        "name": "Code Sharing",
+        "description": "",
+        "file": "shared/concepts/code-sharing",
+        "itemList": [],
+        "isExternal": false,
+        "path": "/more-concepts/code-sharing",
+        "tags": []
+      },
       {
         "id": "monorepo-nx-enterprise",
         "name": "Using Nx at Enterprises",
@@ -1460,6 +1470,16 @@
     "path": "/more-concepts/dependency-management",
     "tags": []
   },
+  "/more-concepts/code-sharing": {
+    "id": "code-sharing",
+    "name": "Code Sharing",
+    "description": "",
+    "file": "shared/concepts/code-sharing",
+    "itemList": [],
+    "isExternal": false,
+    "path": "/more-concepts/code-sharing",
+    "tags": []
+  },
   "/more-concepts/monorepo-nx-enterprise": {
     "id": "monorepo-nx-enterprise",
     "name": "Using Nx at Enterprises",

docs/map.json

@@ -408,6 +408,11 @@
               "id": "dependency-management",
               "file": "shared/concepts/dependency-management"
             },
+            {
+              "name": "Code Sharing",
+              "id": "code-sharing",
+              "file": "shared/concepts/code-sharing"
+            },
             {
               "name": "Using Nx at Enterprises",
               "id": "monorepo-nx-enterprise",

docs/shared/concepts/code-sharing.md

@@ -0,0 +1,21 @@
+# Code Sharing
+
+One of the most obvious benefits of having a monorepo is that you can easily share code across projects. This enables you to apply the Don't Repeat Yourself principle across the whole codebase. Code sharing could mean using a function or a component in multiple projects. Or code sharing could mean using a typescript interface to define the network API interface for both the front end and back end applications.
+
+Code sharing is usually a good thing, but it can cause problems.
+
+## Too Much Sharing
+
+If everyone can use and modify every piece of code, you can run into problems:
+
+### Devs Modifying Another Team's Code
+
+Another team can add complexity to code that your team maintains to satisfy their one use case. This adds an extra burden on you and may make it difficult to adapt that piece of code for other use cases. This can be solved by using a CODEOWNERS file that explicit defines which people in an organization need to approve PRs that touch a particular section of the codebase.
+
+### Outside Devs Using Internal Code
+
+Another team can use a piece of code that is intended to be internal to your project. Now if you change that piece of code, their project is broken. So your team is either locked in to that API or you have to solve problems in another team's project. To solve this, Nx provides a lint rule `enforce-module-boundaries` that will throw an error if a project imports code that is not being exported from the `index.ts` file at the root of a library. Now the `index.ts` file is the definitive published API for that library.
+
+### Projects Depending on the Wrong Libraries
+
+Libraries with presentational components can accidentally use code from a library that holds a data store. Projects with Angular code can accidentally use code from a React project. Projects from team A could accidentally use code in projects that are intended to be only for team B. These kinds of rules will vary based on the organisation, but they can all be enforced automatically using tags and the `enforce-module-boundaries` lint rule.

docs/shared/guides/why-monorepos.md

@@ -8,13 +8,13 @@ If you are familiar with Lerna or Yarn workspaces, check out [this guide](/recip
 
 ## What are the benefits of a monorepo?
 
-- **Shared code and visibility** - Keeps your code DRY across your entire organization. Reuse validation code, UI components, and types across the codebase. Reuse code between the backend, the frontend, and utility libraries.
+- **Shared code and visibility** - [Keeps your code DRY across your entire organization.](/more-concepts/code-sharing) Reuse validation code, UI components, and types across the codebase. Reuse code between the backend, the frontend, and utility libraries.
 
 - **Atomic changes** - Change a server API and modify the downstream applications 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. A monorepo 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 all third-party dependencies, reducing inconsistencies between applications. Less actively developed applications are still kept up-to-date with the latest version of a framework, library, or build tool.
+- **Single set of dependencies** - [Use a single version of all third-party dependencies](/more-concepts/dependency-management), reducing inconsistencies between applications. Less actively developed applications are still kept up-to-date with the latest version of a framework, library, or build tool.
 
 ## Why not just code collocation?