nx: 'rootDir' is expected to contain all source files. Bundle failed: test-icons

To help everyone understand what’s going on, here is the process of how I found the root cause.

What’s the problem

Say we have a monorepo, with several libraries inside, let’s name them lib-a, lib-b and lib-c.

lib-a depends on lib-b and lib-c, in /path-to-monorepo/libs/lib-a/src/foo.tsx, there will be:

import { jim } from '@project-org/lib-b';
import { john } from '@project-org/lib-c';

Path aliases are defined in root tsconfig.base.json (which is extended by root tsconfig.json):

• @project-org/lib-b points to /path-to-monorepo/libs/lib-b/src/bar.ts
• @project-org/lib-c points to /path-to-monorepo/libs/lib-c/src/tor.ts

lib-a has a build target build-lib, which invokes executor @nrwl/web:rollup, another build target build which invokes build-lib and some other targets. lib-b has only a build target build which also invokes executor @nrwl/web:rollup, lib-c has 2 build targets build and build-lib just like lib-a.

Here is the essential part of project.json of lib-a:

{
    "sourceRoot": "libs/lib-a/src",
    "projectType": "library",
    "tags": [],
    "targets": {
        "build": {
            "executor": "@nrwl/workspace:run-commands",
            "options": {
                "commands": ["nx run lib-a:build-lib", "nx run lib-a:build-css"],
                "parallel": false
            }
        },
        "build-lib": {
            "executor": "@nrwl/web:rollup",
            "outputs": ["{options.outputPath}"],
            "options": {
                "outputPath": "dist/libs/lib-a",
                "tsConfig": "libs/lib-a/tsconfig.lib.json",
                "project": "libs/lib-a/package.json",
                "entryFile": "libs/lib-a/src/index.ts",
            }
        }
    }
}

And here is the essential part of project.json of lib-b:

{
    "sourceRoot": "libs/lib-b/src",
    "projectType": "library",
    "tags": [],
    "targets": {
        "build": {
            "executor": "@nrwl/web:rollup",
            "outputs": ["{options.outputPath}"],
            "options": {
                "outputPath": "dist/libs/lib-b",
                "tsConfig": "libs/lib-b/tsconfig.lib.json",
                "project": "libs/lib-b/package.json",
                "entryFile": "libs/lib-b/src/bar.ts",
            }
        }
    }
}

And here is the essential part of project.json of lib-c:

{
    "sourceRoot": "libs/lib-c/src",
    "projectType": "library",
    "tags": [],
    "targets": {
        "build": {
            "executor": "@nrwl/workspace:run-commands",
            "options": {
                "commands": ["nx run lib-c:build-svg", "nx run lib-c:build-lib"],
                "parallel": false
            }
        },
        "build-lib": {
            "executor": "@nrwl/web:rollup",
            "outputs": ["{options.outputPath}"],
            "options": {
                "outputPath": "dist/libs/lib-c",
                "tsConfig": "libs/lib-c/tsconfig.lib.json",
                "project": "libs/lib-c/package.json",
                "entryFile": "libs/lib-c/src/tor.ts",
            }
        }
    }
}

All tsconfig.lib.json extends the root tsconfig.base.json.

Now when we issue nx run lib-a:build, we’ll see an error like:

Error during bundle: Error: /path-to-monorepo/libs/lib-a/src/foo.tsx(5,37): semantic error TS6059: File '/path-to-monorepo/libs/lib-b/src/bar.ts' is not under 'rootDir' '/path-to-monorepo/libs/lib-a/src'. 'rootDir' is expected to contain all source files.

What’s strange is, there’s NO such error for lib-b.

Dig into the source code of nx to find the root cause

We can add --verbose option when building lib-a to see where exactly the error is thrown, and it takes us here, hmm, doesn’t help too much.

Let’s dive directly into rollup executor then.

NOTE the original error says TS6059 - which means it is thrown by tsc. Although the library is transpiled by babel by default, tsc must be invoked somewhere.

Ah, here it is. But, hmm, still doesn’t know what could go wrong.

Let’s take a look what createCompilerOptions(options, dependencies) produces.

But hold on, options is rollup options, what about dependencies? It’s the calculated project dependencies, which looks like:

[
  {
    name: '@project-org/lib-c',
    outputs: [ 'dist/libs/lib-c' ],
    node: { type: 'lib', name: 'lib-c', data: [Object] }
  },
  // ...
]

However we’ll find @project-org/lib-b missing in the list. Stay calm, we’ll come back to this later.

With this list of dependencies, createCompilerOptions(options, dependencies) produces:

{
  rootDir: '/path-to-monorepo/libs/lib-a/src',
  allowJs: false,
  declaration: true,
  paths: {
    '@project/lib-b': [ 'libs/lib-b/src/foo.ts' ],
    '@project/lib-c': [ 'dist/libs/lib-c' ],
    // ...
  }
}

Huh? @project/lib-c points to dist/libs/lib-c instead of libs/lib-c/src/tor.ts, why?

In packages/workspace/src/utilities/buildable-libs-utils.ts, computeCompilerOptionsPaths() reads path aliases defined in project’s tsconfig.json and update them, in updatePaths(), paths[dep.name] = dep.outputs. Ah ha, this is where the outputs folder dist/libs/lib-c is used to replaced the original path. And because @project-org/lib-b is missing in the dependency list, its path alias stays intact.

What’s inside dist/libs/lib-c? Generated .d.ts files, transpiled .js files, etc., anyway NO .ts source files, thus won’t break TS check performed by rollup-plugin-typescript2.

However, @project/lib-b is not so lucky, libs/lib-b/src/foo.ts is a TS source file itself outside of rootDir, thus tsc will complain.

Now, the question becomes, why is @project-org/lib-b missing in the dependency list?

Let’s get back to const { target, dependencies } = calculateProjectDependencies(...), one of the arguments of this function call, projectGraph, is read from node_modules/.cache/nx/nxdeps.json (default path).

And next is the essential part.

const depNode = projGraph.nodes[dep] || projGraph.externalNodes[dep];, where projGraph.nodes looks like:

{
    "lib-b": {
        "name": "lib-b",
        "type": "lib",
        "data": {
            "root": "libs/lib-b",
            "sourceRoot": "libs/lib-b/src",
            "projectType": "library",
            "tags": [],
            "targets": {
                "build": {
                    "executor": "@nrwl/web:rollup",
                    "outputs": ["{options.outputPath}"],
                    "options": {
                        "outputPath": "dist/libs/lib-b",
                        "tsConfig": "libs/lib-b/tsconfig.lib.json",
                        "project": "libs/lib-b/package.json",
                        "entryFile": "libs/lib-b/src/bar.ts",
                        "external": ["react/jsx-runtime"],
                        "rollupConfig": "@nrwl/react/plugins/bundle-rollup",
                    }
                }
            },
            "files": [
                // ...
            ]
        }
    },
    "lib-c": {
        "name": "lib-c",
        "type": "lib",
        "data": {
            "root": "libs/lib-c",
            "sourceRoot": "libs/lib-c/src",
            "projectType": "library",
            "tags": [],
            "targets": {
                "build": {
                    "executor": "@nrwl/workspace:run-commands",
                    "options": {
                        "commands": ["nx run lib-c:build-svg", "nx run lib-c:build-lib"],
                        "parallel": false
                    }
                },
                "build-lib": {
                    "executor": "@nrwl/web:rollup",
                    "outputs": ["{options.outputPath}"],
                    "options": {
                        "outputPath": "dist/libs/lib-c",
                        "tsConfig": "libs/lib-c/tsconfig.lib.json",
                        "project": "libs/lib-c/package.json",
                        "entryFile": "libs/lib-c/src/tor.ts",
                        "external": ["react/jsx-runtime"],
                        "rollupConfig": "@nrwl/react/plugins/bundle-rollup",
                    }
                }
            },
            "files": [
                // ...
            ]
        }
    }
}

if (isBuildable(targetName, depNode)), targetName is build-lib since rollup executor is invoked by build-lib of lib-a.

Let’s look at the definition of isBuildable(), it determines whether a dependency is buildable by:

node.data.targets &&
    node.data.targets[target] &&
    node.data.targets[target].executor !== ''

As for lib-c, it returns true. But as for lib-b, since it doesn’t have a build-lib target, that condition returns false! This is why lib-b was missing in the dependency list.

Solution

To make nx thinks lib-b as buildable, we need to define a build-lib target for it. Here is the updated version of project.json of lib-b:

{
    "sourceRoot": "libs/lib-b/src",
    "projectType": "library",
    "tags": [],
    "targets": {
        "build": {
            "executor": "@nrwl/workspace:run-commands",
            "options": {
                "commands": ["nx run lib-b:build-lib"],
                "parallel": false
            }
        },
        "build-lib": {
            "executor": "@nrwl/web:rollup",
            "outputs": ["{options.outputPath}"],
            "options": {
                "outputPath": "dist/libs/lib-b",
                "tsConfig": "libs/lib-b/tsconfig.lib.json",
                "project": "libs/lib-b/package.json",
                "entryFile": "libs/lib-b/src/bar.ts",
            }
        }
    }
}

To summarize it, all internal dependencies of a library must have a build target of the same name, in order to make nx treat them as buildable.

Other workarounds

• Use a customized rollup config to remove rollup-plugin-typescript2.
• Change path alias of @project-org/lib-b in tsconfig.base.json to "@project-org/lib-b": ["dist/libs/lib-b", "libs/lib-b/src/bar.ts"]
  • This has a downside that, in our editor like vscode, @project-org/lib-b will point to dist directory which contains .d.ts files but not real source .ts files, not a good development experience.
• Add a path alias "@project-org/lib-b": ["dist/libs/lib-b"] in libs/lib-b/tsconfig.lib.json
  • This is better than the previous one, @project-org/lib-b still points to libs/lib-b/src/bar.ts in our editor (because of the path alias "@project-org/lib-b": ["libs/lib-b/src/bar.ts"] in root tsconfig.json), while "@project-org/lib-b": ["dist/libs/lib-b"] in libs/lib-b/tsconfig.lib.json overrides it - when parsedTSConfig.compilerOptions.paths exists, path aliases in parsedTSConfig.extends are bypassed.

Any update on this? all workaround mentioned above didn’t work for me. I am using nx v14.3.6 with react library and tried also with latest nx version v15.2.1 as well, but the result is same.

adding the dist path(s) to the tsconfig did the trick for me.

Thats for sure works, but is hard to develop this way. You have to manually build libraries in correct order. You are also importing now from DIST, means changes you make are not seamless applied to the rest of the project.

@7alip Must have saved me hours with your comment. Thank you

The 'rootDir' is expected to contain all source files error can be caused for a number of reasons. Some might be legit TS setup issues leading to trying to compile files that are outside of the project root dir, while in a lot of cases, it’s down to how we handle “buildable” libraries in Nx incremental builds scenarios.

As explained (great detective work! 👏🏻 ) by @athrunsun in https://github.com/nrwl/nx/issues/11289#issuecomment-1195616035, Nx executors that support the incremental builds scenarios, look for targets with the same name as the build target name of the top-level project being built. The found targets’ info will be used to collect their output paths and remap on the fly the TS path mappings existing in the tsconfig file at the root of your workspace to point to the compiled source. The remapping is done so we can provide the best possible DX. By default, your projects point to the dependency sources (that’s what your IDE will use) and at build time, it will point to the dependency compiled code to avoid building it again. When looking up for the dependencies targets, if they are not found, the TS path mapping will remain pointing to the source code of the dependency and given it’s a different project, its location will be outside of the rootDir of the project that depends on it. Hence the error.

Also, if the dependencies between targets are not correctly configured (using targetDefaults and/or dependsOn), the task graph won’t be constructed correctly, and therefore, the targets from dependencies won’t be found leading to the same issue.

Please note that error will also happen if the dependencies of buildable libraries are not buildable (have a target to build the library). In such cases, no target will be found because there’s none and the same error will be thrown. Buildable libraries must depend on other buildable libraries. There are a couple of executors that support inlining non-buildable libraries into buildable libraries, but that feature is highly experimental and it’s not recommended.

Identifying the buildable target from the dependencies has always been the challenge and we’ve had a constraint of keeping the target names aligned. Nx generators always generate “build” target, but of course, in real-world scenarios, developers can change those names and use something else. This is often the case when needing to do extra tasks and new targets are added and composed to build a project.

In Nx 16.6.0, we introduced a new way to identify the build target of dependent buildable libraries. The new way doesn’t rely on the targets having the same name, but rather on the information available in the task graph. It’s still key to have the target dependencies correctly configured. This behavior is not yet enabled by default, but you can try it by setting the following env var: NX_BUILDABLE_LIBRARIES_TASK_GRAPH=true.

We’re trying to get feedback whether this new way works as expected before turning it on by default. Could you try it and let us know how it goes? We want to know:

• We don’t break existing setups (with the same target name)
• It handles buildable library targets with different names (provided they are part of the task graph, so, target dependencies must be correctly configured)

If you already solved your issue by ensuring the same target name, you could still try this and provide feedback. As mentioned above, we want to make sure the new way doesn’t break existing scenarios.

If it doesn’t work for you, please try to provide a reproduction so the feedback is actionable and we can troubleshoot it.

In my case, I noticed that when I moved some files to a different folder, some relative import paths were automatically changed.

It was import { } from 'libs/types/src...' but should be import { } from '../common'

Changing the tsconfig paths helped compiling the project, but it raises another error `Error: Cannot find module ‘@my-org/lib-b’, because the imported lib path is not changed in the compiled file