Using `rootDirs` in a monorepo setting results in unnecessary subfolders like `src` being generated in the `outDir`

Question

Using `rootDirs` in a monorepo setting results in unnecessary subfolders like `src` being generated in the `outDir`

I am in the process of planning a monorepo TypeScript project structured as follows:

/ (root)
+--backend/
|  +-src/
|  \-tsconfig.json
+--shared/
|  \-src/
\--frontend/
   \-src/

The tsconfig.json file looks like this:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "outDir": "./dist",
    "strict": true,
    "baseUrl": "./src",
    "paths": {
      "shared": [
        "../../shared/src"
      ]
    },
    "rootDirs": [
      "./src",
      "../shared/src"
    ],
    "esModuleInterop": true
  }
}

Upon running tsc within the backend directory, the output structure is currently:

/ (root)
+-backend/
  +-dist/
  | +-backend/
  | | +-src/
  | \-shared/
  |   \-src/
  +-src/
  \-tsconfig.json

In this output, both dist/backend and dist/shared directories contain an additional src subdirectory. However, I would like them to only have the compiled JavaScript files without the src directory:

/ (root)
+-backend/
  +-dist/
  | +-backend/
  | \-shared/
  +-src/
  \-tsconfig.json

Is this achievable? If so, how can I achieve it?

typescript dependencies tsconfig monorepo

Answer 1

Answer №1

analysis

In Typescript, the rootDir setting is crucial for determining the output directory structure. It's important to note that using multiple rootDirs will result in tsc identifying the common parent directory and treating it as the main rootDir.
This explains why you might be experiencing a certain output directory structure when dealing with multiple rootDirs.

solution: Organize your monorepo into distinct Typescript sub-projects

A Typescript project can be defined by its own tsconfig file, making it self-contained and bounded by its designated rootDir. This approach aligns well with the principles of encapsulation.

You have the option to set up separate projects within different directories, each having its own tsconfig configuration and rootDir. The dependencies between these projects can be managed through Typescript Project References.

Although the term "project" used by Typescript might seem broad, considering them as subprojects can provide better clarity.

It is recommended to structure your repository as follows:

.
├── dist
└── src
    ├── tsconfig.json
    ├── shared
    │   ├── index.ts
    │   └── tsconfig.json
    ├── backend
    │   ├── index.ts
    │   └── tsconfig.json
    └── frontend
        ├── index.ts
        └── tsconfig.json

Upon compilation, the resulting code structure should resemble this:

.
├── dist
│   ├── shared
│   ├── backend
│   └── frontend
└── src

Example tsconfigs

src/tsconfig.json

Even if there are no files at the root level, this tsconfig can serve as the central configuration holding common settings. Issuing tsc --build src would then build the entire project structure (use --force for full rebuild).

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../dist/",
    },
    "files": [],
    "references": [
      { "path": "./shared" },
      { "path": "./backend" },
      { "path": "./frontend" }
    ]
  }

src/shared/tsconfig.json

The shared project does not import other projects, containing only internal references and dependencies listed in its package.json. For stricter isolation, consider assigning it a dedicated package.json.
```
  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/shared",
      "composite": true
    }
  }
```

src/backend/tsconfig.json

The backend project can reference the shared due to the declared relationship.

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/backend",
      "composite": true
    },
    "references": [
      { "path": "../shared" }
    ]
  }

src/frontend/tsconfig.json

The frontend project can import both shared and backend thanks to their declared relationships.

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/frontend",
      "composite": true
    },
    "references": [
      { "path": "../shared" },
      { "path": "../backend" }
    ]
  }

Build Examples

tsc --build src compiles the entire src structure

tsc --build src/backend builds the backend along with shared (if changes have occurred since the last build).

Answer 2

analysis

In Typescript, the rootDir setting is crucial for determining the output directory structure. It's important to note that using multiple rootDirs will result in tsc identifying the common parent directory and treating it as the main rootDir.
This explains why you might be experiencing a certain output directory structure when dealing with multiple rootDirs.

solution: Organize your monorepo into distinct Typescript sub-projects

A Typescript project can be defined by its own tsconfig file, making it self-contained and bounded by its designated rootDir. This approach aligns well with the principles of encapsulation.

You have the option to set up separate projects within different directories, each having its own tsconfig configuration and rootDir. The dependencies between these projects can be managed through Typescript Project References.

Although the term "project" used by Typescript might seem broad, considering them as subprojects can provide better clarity.

It is recommended to structure your repository as follows:

.
├── dist
└── src
    ├── tsconfig.json
    ├── shared
    │   ├── index.ts
    │   └── tsconfig.json
    ├── backend
    │   ├── index.ts
    │   └── tsconfig.json
    └── frontend
        ├── index.ts
        └── tsconfig.json

Upon compilation, the resulting code structure should resemble this:

.
├── dist
│   ├── shared
│   ├── backend
│   └── frontend
└── src

Example tsconfigs

src/tsconfig.json

Even if there are no files at the root level, this tsconfig can serve as the central configuration holding common settings. Issuing tsc --build src would then build the entire project structure (use --force for full rebuild).

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../dist/",
    },
    "files": [],
    "references": [
      { "path": "./shared" },
      { "path": "./backend" },
      { "path": "./frontend" }
    ]
  }

src/shared/tsconfig.json

The shared project does not import other projects, containing only internal references and dependencies listed in its package.json. For stricter isolation, consider assigning it a dedicated package.json.
```
  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/shared",
      "composite": true
    }
  }
```

src/backend/tsconfig.json

The backend project can reference the shared due to the declared relationship.

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/backend",
      "composite": true
    },
    "references": [
      { "path": "../shared" }
    ]
  }

src/frontend/tsconfig.json

The frontend project can import both shared and backend thanks to their declared relationships.

  {
    "compilerOptions": {
      "rootDir": ".",
      "outDir": "../../dist/frontend",
      "composite": true
    },
    "references": [
      { "path": "../shared" },
      { "path": "../backend" }
    ]
  }

Build Examples

tsc --build src compiles the entire src structure

tsc --build src/backend builds the backend along with shared (if changes have occurred since the last build).

Using `rootDirs` in a monorepo setting results in unnecessary subfolders like `src` being generated in the `outDir`

Answer №1

analysis

solution: Organize your monorepo into distinct Typescript sub-projects

Similar questions

Unused code splitting chunk in React production build would improve performance and efficiency of

Preventing nested prototype methods from being transferred between objects in a WebWorker

Tips for Simplifying Complex Switch Cases with Object Literals in TypeScript

Distinguishing the switch function from the React switch operator (jsx, tsx)

The map function is calling an unresolved function or method named "map"

Error: The object 'exports' is not defined in geotiff.js at line 3

Encountered an issue trying to access undefined properties while reading 'PP'

TypeScript overload does not take into account the second choice

Vite deciding to generate its own node_modules directory within the workspace rather than depending on a monorepo

Is there a way to ensure that the observer.next(something) received the value before executing observer.complete()?

What is the best way to retrieve data from MySQL for the current month using JavaScript?

An error has occurred in Angular: No routes were found that match the URL segment 'null'

Activate the event when the radio button is changed

When configuring Gatsby with Typescript, you may encounter the error message: "You cannot utilize JSX unless the '--jsx' flag is provided."

Issue encountered while attempting to utilize a basic redux reducer to define a boolean value, regarding a mismatch in overrides

What is the best way to ensure the website theme remains consistent after a refresh in React?

The type 'Bar<T>' cannot be assigned to type 'T extends number ? number | Bar<T> : Bar<T>'

the ng-repeat directive disables input controls within the tfoot

Issue with triggering blur event in Internet Explorer while using Angular 2+

Underwhelming scroll speed when working with 9 columns in react-virtualized