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.
Can you change the folder structure later?
Section titled “Can you change the folder structure later?”Yes. Don't be too anxious about choosing the exact right structure from the beginning. Moving or renaming a project folder is a regular mv, and deleting one is a regular rm, the same as in any repository. Tooling doesn't factor into the decision, so pick the structure that helps developers find things, and change it when your organization changes.
Example workspace
Section titled “Example workspace”Let's use Acme 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.
Directoryapps/
Directorybooking/
- …
Directorycheck-in/
- …
Directorylibs/
Directorybooking/ <---- grouping folder
Directoryfeature-shell/ <---- project
- …
Directorycheck-in/
Directoryfeature-shell/
- …
Directoryshared/ <---- grouping folder
Directorydata-access/ <---- project
- …
Directoryseatmap/ <---- grouping folder
Directorydata-access/ <---- project
- …
Directoryfeature-seatmap/ <---- project
- …
Sharing projects
Section titled “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.
Directorylibs/
Directorybooking/
Directorydata-access/ <---- app-specific project
- …
Directoryshared/
Directorydata-access/ <---- shared project
- …
Directoryseatmap/
Directorydata-access/ <---- shared project
- …
Directoryfeature-seatmap/ <---- shared project
- …