'rootDir' is expected to contain all source files
Asked Answered
A

7

58

I have an Angular CLI workspace containing two library projects, foo and bar. When I build the second of the two libraries, foo, the build fails with the following error:

error TS6059: File '/code/projects/bar/src/lib/types.ts' is not under 'rootDir' '/code/projects/foo/src'. 'rootDir' is expected tocontain all source files.

Error: error TS6059: File '/code/projects/bar/src/lib/types.ts' is not under 'rootDir' '/code/projects/foo/src'. 'rootDir' is expected to contain all source files.

    at Object.<anonymous> (/code/node_modules/ng-packagr/lib/ngc/compile-source-files.js:53:68)
    at Generator.next (<anonymous>)
    at /code/node_modules/ng-packagr/lib/ngc/compile-source-files.js:7:71
    at new Promise (<anonymous>)
    at __awaiter (/code/node_modules/ng-packagr/lib/ngc/compile-source-files.js:3:12)
    at Object.compileSourceFiles (/code/node_modules/ng-packagr/lib/ngc/compile-source-files.js:19:12)
    at Object.<anonymous> (/code/node_modules/ng-packagr/lib/ng-v5/entry-point/ts/compile-ngc.transform.js:26:32)
    at Generator.next (<anonymous>)
    at /code/node_modules/ng-packagr/lib/ng-v5/entry-point/ts/compile-ngc.transform.js:7:71
    at new Promise (<anonymous>)

I have reproduced the error in a sandbox repo on GitHub here. I have simplified the code to as much as I can while still experiencing the error. You can reproduce the error by executing npm run build on the rootDir-expect-all-source-files-error branch. What is the cause of the error? May this be a bug with ng-packagr or ngc or tsc? Or is it simply a configuration issue?

Observations

Below are code changes with which I can make the build pass, but I would like to know what is causing the error with the code as is.

bar.component.ts

Build fails

export class BarComponent {

  list = this.barService.list();

  constructor(private barService: BarService) {}
}

Build passes

Initialize list property in constructor instead of inline

export class BarComponent {

  list;

  constructor(private barService: BarService) {
    this.list = this.barService.list();
  }
}

bar.service.ts

Build fails

import { Injectable } from '@angular/core';
import { List, Item } from './types';

@Injectable({
  providedIn: 'root'
})
export class BarService {

  private _list: List = [];

  constructor() { }

  add(item: Item): void {
    this._list.push(item);
  }

  list(): List {
    return this._list;
  }
}

Build passes

Remove the data types

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class BarService {

  private _list: any[] = [];

  constructor() { }

  add(item: any): void {
    this._list.push(item);
  }

  list(): any {
    return this._list;
  }
}
Absinthe answered 14/8, 2018 at 21:32 Comment(1)
The displayed error makes sense from TypeScript perspective, however I don't really have knowledge of Angular CLI. As you don't set rootDir property in your tsconfig, Angular CLI seems to internally restrict it to the root of the library you want to compile. Then, if you import another lib outside, TypeScript rightfully complains. Concerning rootDir have a look here: #57422958 (disclaimer: answer from me).Minardi
S
11

This looks like the problem that is occurring due to the import types which was introduced in TypeScript 2.9. When emitted these are not being rewired properly see line 3.

dist/bar/lib/bar.component.d.ts(5,11):

export declare class BarComponent implements OnInit {
    private barService;
    list: import("projects/bar/src/lib/types").Item[]; 
    constructor(barService: BarService);
    ngOnInit(): void;
}

In the above emitted dts, list: import("projects/bar/src/lib/types").Item[]; should be something like import("./types").Item[]; instead.

A workaround for this can be that from your code instead infering the type, you explicitly set it.

in bar.component.ts change the below;

list = this.barService.list();

to:

list: Item[] = this.barService.list();

This will remove the type import and the consuming library will build.

I also checked a bit with future versions of TypeScript, it is still an issue in TypeScript 3.0.1, but it looks like it has been addressed in dev version of TypeScript 3.1.0, ie 3.1.0-dev.20180813

Sivan answered 15/8, 2018 at 15:0 Comment(2)
A.Agius, I would like to verify that the dev version of TypeScript solves this issue in my project, but I am getting the TypeScript mismatch error when building the library. Can you assist with overcoming this issue here?Absinthe
Great, thanks! With your help I was able to confirm that the build error occurs in version 3.1.0-dev.20180810 and before, but the build is successful with version 3.1.0-dev.20180813 as you have pointed out.Absinthe
L
11

I had the same issue, but the solution of @Agius did not help.

I had:

Angular Workspace
  - projects
      - lib1
      - lib2
  - src
      - test application

In fact I had moved a component from lib2 to lib1, by dragging the folder in WebStorm. By doing this, the references in lib2 to that component were not removed but updated and pointed to the source-folder of lib1. I forgot to remove these references which were no longer needed in lib2. After removing all references to the component in lib2, that library compiled.

I had to remove the references in

  • public_api.ts
  • ./lib/lib2.module.ts

Maybe there are more references in your project.

Lenten answered 28/11, 2018 at 12:28 Comment(0)
P
11

I have a typescript project and faced an issue complaining about imports with the same error. I have solved it by correcting the value of include in tsconfig.json file as below

{
  "compilerOptions": {
    "module": "CommonJS",
    "target": "ES2017",
    "noImplicitAny": true,
    "preserveConstEnums": true,
    "outDir": "./dist",
  },
  "exclude": ["node_modules", "**/*.test.ts"],
  "include": ["src"]
}

Hope this may help.

Presentationism answered 28/12, 2021 at 10:38 Comment(1)
It is worth noting that "rootDir": property in tsconfig.json needs to be removed.Pyne
C
6

the issue is related to the import statements where the import path is not being provided properly.

For example:-

 import * from '../.././../tools1/tools2/tools/demo';

should be

import * from '@tools/tools/demo';

here @tools is considered as the root directory. Note:- above mentioned path is just an example.

Cordeliacordelie answered 20/7, 2020 at 12:52 Comment(0)
H
5

if you're using https://nx.dev and you get this error...

i also encountered this problem...

it was killing me... i couldn't figure out why nx didn't build right... it was giving me tons of errors about one of my referenced project @scope1/lib2 and all of its .ts files being outside the project that referenced it... i also noticed that the dep-graph had @scope1/lib2 but there was no dependency arrow from the referencing library...

i found this fix:

rm -rf node_modules/.cache

i'm guessing nx had something in the cache that was wrong... after deleting, the dep-graph finally showed the link properly and the build started working

Hickox answered 20/12, 2021 at 15:48 Comment(2)
Thanks! This is the one that I faced while using nx and this fix helped solve the issueCristinacristine
I had a similar problem. In my structure there was a index.d.ts beside my index.ts. This was the problem for me.Eighteenth
C
2

For NX workspace this error "...is not under 'rootDir'. ..." can say that you imported some lib1 to another buildable lib2. Also references inc ts-config doesn't work for me...

check this comment: https://mcmap.net/q/1419423/-angular-monorepo-error-ts6059-file-39-ng-youtube-api-service-ngtypecheck-ts-39-is-not-under-39-rootdir-39-39-rootdir-39-is-expected-to-contain-all-source-files

Custom answered 18/6, 2023 at 11:27 Comment(0)
W
0

For my NX Repo, I was getting this error for *.ngtypecheck.ts files that were automatically generated by @ngtools/webpack.

To fix the error, I had to remove the reference from implicitDependencies within the project.json file.

So, we have this project:

{
  "name": "icons"
}

And then this project that references icons project:

{
  "name": "button",
  "implicitDependencies": ["!icons"]
}

By removing "!icons" from the list the error went away.

Waddington answered 15/2 at 20:50 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.