66eaf2fc74
This PR removes the `/nx-api` pages from `nx-dev`. They are already redirected from `/nx-api` to either `/technologies` or `/reference/core-api` URLs. e.g. `/nx-api/nx` goes to `/reference/core-api/nx` and `/nx-api/react` goes to `/technologies/react/api` **Changes**: - Remove old `nx-api.json` from being generated in `scripts/documentation/generators/generate-manifests.ts` -- this was used to generate the sitemap - Remove `pages/nx-api` from Next.js app since we don't need them - Remove workaround from link checker `scripts/documentation/internal-link-checker.ts` -- the angular rspack/rsbuild and other workarounds are gone now that they are proper docs in `map.json` - Update Powerpack/Remote Cache reference docs to exclude API documents (since they are duplicated in the Intro page) -- `nx-dev/models-document/src/lib/mappings.ts` - All content in `docs` have been updated with new URL structure **Note:** Redirects are already handled, and Claude Code was used to verify the updated `docs/` URLs (see report below). The twelve 404s links were updated by hand. ## Verification Report https://gist.github.com/jaysoo/c7863fe7e091cb77929d1976165c357a
73 lines
3.1 KiB
Markdown
73 lines
3.1 KiB
Markdown
---
|
|
title: Folder Structure
|
|
description: Learn about organizing your Nx monorepo with effective folder structures, and how to easily move or remove projects as your organization evolves.
|
|
---
|
|
|
|
# Folder Structure
|
|
|
|
Nx can work with any folder structure you choose, but it is good to have a plan in place for the folder structure of your monorepo.
|
|
|
|
Projects are often grouped by _scope_. A project's scope is either the 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. Projects can be moved or renamed using the [`@nx/workspace:move` generator](/reference/core-api/workspace/generators/move).
|
|
|
|
For instance, if a project under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this:
|
|
|
|
```shell
|
|
nx g move --project booking-some-project shared/some-project
|
|
```
|
|
|
|
## Remove Generator
|
|
|
|
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/reference/core-api/workspace/generators/remove).
|
|
|
|
```shell
|
|
nx g remove booking-some-project
|
|
```
|
|
|
|
## Example Workspace
|
|
|
|
Let's use Nrwl Airlines as an example organization. This organization has two apps, `booking` and `check-in`. In the Nx workspace, projects related to `booking` are grouped under a `libs/booking` folder, projects related to `check-in` are grouped under a `libs/check-in` folder and projects 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 projects 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.
|
|
|
|
```text
|
|
apps/
|
|
booking/
|
|
check-in/
|
|
libs/
|
|
booking/ <---- grouping folder
|
|
feature-shell/ <---- project
|
|
|
|
check-in/
|
|
feature-shell/
|
|
|
|
shared/ <---- grouping folder
|
|
data-access/ <---- project
|
|
|
|
seatmap/ <---- grouping folder
|
|
data-access/ <---- project
|
|
feature-seatmap/ <---- project
|
|
```
|
|
|
|
## Sharing Projects
|
|
|
|
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 projects 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` project 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.
|
|
|
|
```text
|
|
libs/
|
|
booking/
|
|
data-access/ <---- app-specific project
|
|
|
|
shared/
|
|
data-access/ <---- shared project
|
|
|
|
seatmap/
|
|
data-access/ <---- shared project
|
|
feature-seatmap/ <---- shared project
|
|
```
|