14

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

6 Answers 6

14

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 .).

4
  • 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.
    – Itay Ganor
    Commented Apr 9, 2020 at 13:50
  • 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. Commented Apr 15, 2020 at 8:26
  • 1
    See this answer for info on rootDir and using Project Reference. Think will start to make a lot more sense.
    – Inigo
    Commented Apr 29, 2020 at 1:23
  • 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.
    – Venryx
    Commented Jun 30, 2021 at 0:02
4

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.

3
  • 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!
    – Tirias
    Commented Jul 2, 2021 at 20:28
  • 2
    @Tirias 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).
    – rrmesquita
    Commented Jul 4, 2021 at 7:42
  • Worked like a charm without needing to use path aliases and neither path references. Thanks!
    – Tirias
    Commented Jul 6, 2021 at 5:29
4

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

1

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

1
  • 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. Commented Sep 20, 2021 at 19:33
0

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
]
1
  • I tried this, did not make any difference. Error is the same.
    – Srk95
    Commented Jan 11 at 7:06
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.