nx/docs/shared/concepts/decisions/folder-structure.md

3.1 KiB

title description
Folder Structure 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.

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.

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.

  libs/
    booking/
      data-access/           <---- app-specific project

    shared/
      data-access/           <---- shared project

      seatmap/
        data-access/         <---- shared project
        feature-seatmap/     <---- shared project