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.

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:

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.

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.

• 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

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

        • …