"'rootDir' is expected to contain all source files" in monorepo

Question

I'm working on converting a large(ish) monorepo into TypeScript for a client, however, I'm pretty new to TS myself and have run into an error that I can't find an obvious fix for.

TS6059: File '[path to repo root]/packages/config/globals.ts' is not under 'rootDir' '[path to repo root]/packages/components/src'. 'rootDir' is expected to contain all source files.

The globals.ts file isn't supposed to live in the components package, it belongs to the config package so I don't really understand the error.

I have a main tsconfig file in the root of the repo (https://github.com/serge-web/serge/blob/feature/333-game-admin-channel/tsconfig.json) and then each package has it's own tsconfig file which extends that one. The one for the components package is here: https://github.com/serge-web/serge/blob/feature/333-game-admin-channel/packages/components/tsconfig.json

I assume I am extending the tsconfig files in the packages incorrectly or I have used references incorrectly but I can't find the correct way to do this.

Here is a link to the repo if you need to see the structure: https://github.com/serge-web/serge/tree/feature/333-game-admin-channel

Silvas

Answer 1

In the end the fix was to remove any reference to rootDir from all files other than the tsconfig.json file in the root (which I left as .).

Silvas

While it does solve the problem, don't you think rootDir exists for a reason? I have the same issue in my project, but I don't feel like deleting rootDir is safe. – Capriola

It is definitely an irritating answer, yes. rootDir is the pattern that the typescript builder users for the output folder, so removing it means that my build folder doesn't get output the way I wanted it to, however I just added another node script to clean the folder up, it's far from ideal but it does the job. – Silvas

See this answer for info on rootDir and using Project Reference. Think will start to make a lot more sense. – Cyd

I had the same issues as the OP, and once I did the work to convert to Project References, everything just works so much more smoothly! Fair warning, it did take a while for me to understand how to configure everything properly (mainly fixes for my [bad] "workarounds" for gluing things together), but now that that's done, it works great. Faster builds, no conflicts with webpack and ts-loader, retained the ability to jump-to-source in other subrepos (using the declarationMap flag), etc. – Lymphatic

Answer 2

The only thing that worked for me was explicitly add the package containing foreign code as a dependency in package.json:

{
    "dependencies": {
        "@packages/name": "*"
    }
}

In my setup I'm not using Lerna, just raw Yarn Workspaces with both TypeScript and JavaScript packages.

Plenary

I am trying to make this work in your way. Could you please elaborate a bit more? I do not want to use path aliases, just add my own monorepo projects as dependencies for other subprojects. Is that possible? Thanks! – Hardset

@Hardset actually yes. I know two ways of accomplishing that. 1) Upload your monorepo projects to npm then npm i them. 2) Use "npm link" to symlink your project as a global npm dep (local only) (docs.npmjs.com/cli/v7/commands/npm-link). – Plenary

Worked like a charm without needing to use path aliases and neither path references. Thanks! – Hardset

Answer 3

I used to have the same problem.

references is the correct way to solve this problem.

My monorepo app file structure is like this:

MyMonorepo
├── lerna.json
├── package.json
├── packages
│   ├── packageA
│   │   ├── package.json
│   │   ├── src
│   │   │   ├── index.ts
│   │   └── tsconfig-build.json
│   └── packageB
│       ├── package.json
│       ├── src
│       │   └── index.ts
│       └── tsconfig-build.json
├── tsconfig.json
└── yarn.lock

And packageA used some packageB's components.

Config packageA's tsconfig-build.json like this:

{
    "extends": "../../tsconfig.json",
    "include": ["src/**/*"],
    "exclude": ["src/**/*.test.ts", "src/**/*.test.tsx", "**/demos/*.ts", "**/demos/*.tsx"],
    "compilerOptions": {
        "rootDir": "./src",
        "outDir": "./dist/types",
        "composite": true,
        "emitDeclarationOnly": true,
        "skipLibCheck": true
    },
    "references": [{ "path": "../packageB/tsconfig-build.json" }]
}

That references config solved my problem.

Doc: https://www.typescriptlang.org/docs/handbook/project-references.html

Extramural

Answer 4

With me the .ts was found in the typings directory. Changing the extension from filename.ts to filename.d.ts solved the problem. All other files were named this way, it was old code, I have no idea why that one file had the extension .ts and not .d.ts

Haleyhalf

Worked! Thank you. Perhaps you were using .ts instead of d.ts because your *d.ts files were not typechecked? That's what happens when --skipLibCheck is used. – Beadruby

Answer 5

With Angular 15 and NX monorepo I noticed that the ts-config.base.json property paths affected on the sequence of the libs of their order. If you have a lib with dependencies of other libs inside you need to put dependencies above the lib which uses them.

paths: [
  @lib/which-use-other-libs,
  @smaller/lib
  @constants/lib
  @lib/which-use-smaller-lib // <- here will be an error, should be before smaller/lib
]

Dwaynedweck

I tried this, did not make any difference. Error is the same. – Dimeter

Answer 6

Here is a possible solution for someone using NX monorepo.

Check

1. Are your libraries buildable?
2. Do you have generatePackageJson set to true in your project.json or nx.json
3. Check if you have a package.json inside the library directory that has name and version

Note: Step 3 will be automatically done if you have created the library as buildable using nx. But if you missed somehow, add it manually.

Coloratura