`ignoreUnusedDeps` causes build to fail when ts path-mapped libs live outside project root

[jaxcksn]

With what library do you have an issue?

native-federation

Reproduction of the bug/regression with instructions

Reproduction Repo

See this minimum reproduction repo:
https://github.com/jaxcksn/nf-ignore-unused-deps-bug-repro

I added root package.json so you should just be able to run npm run setup and then npm run start:host from that repo root to get started.

Step by Step

1. Setup a native federation remote and host angular projects, plus a shared angular component library, all children of a root folder:

If you use the angular CLI, you can scaffold it with:

mkdir repro
cd repro
ng new host
ng new remote
ng new shared --no-create-application
cd shared
ng generate library shared

And then setup native federation in host and remote using the angular CLI.
You should end up with something like this:

root/
├─ host/
│  ├─ angular.json
│  ├─ tsconfig.json
│  ├─ ...
│  ├─ federation.config.js
├─ remote/
│  ├─ angular.json
│  ├─ tsconfig.json
│  ├─ .,.
│  ├─ federation.config.js
├─ shared/
│  ├─ ...
│  ├─ projects/shared/src/
│  │  ├─public-api.ts
│  ├─ angular.json

2. In the host and remote tsconfig.json add the following path mapping:

"compilerOptions": {
  "paths": {
    "shared": [
      "../shared/projects/shared/src/public-api.ts"
    ]
  }
}

3. Setup the host and remote federation.config.js like so:

const { withNativeFederation, shareAll } = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'Host',

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },
  skip: ['rxjs/ajax', 'rxjs/fetch', 'rxjs/testing', 'rxjs/webSocket'],

  features: {
    ignoreUnusedDeps: true,
  },

  sharedMappings: ['shared'],
});

4. Import something from the shared library in the host and remote:

import { sharedValue } from 'shared';

5. Try to serve/build the host or remote application:

ng serve

You should see an error like so:

An unhandled exception occurred: C:\repro\shared\projects\shared\src\util\index.ts is outside of root C:\repro\host

and then in the angular log, it'll show something like:

[error] Error: C:\repro\shared\projects\shared\src\util\index.ts is outside of root C:\repro\host
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:85:27)
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:107:36)
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:107:36)
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:107:36)
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:107:36)
    at traverseFilesystem (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\traverse-filesystem.js:107:36)
    at generateUnassignedFileInfo (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\file-info\generate-unassigned-file-info.js:19:67)
    at parseProject (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\main\parse-project.js:14:95)
    at init (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\main\init.js:31:52)
    at getProjectData (C:\repro\host\node_modules\@softarc+sheriff-core@0.19.2_typescript@5.9.3\node_modules\@softarc\sheriff-core\src\lib\api\get-project-data.js:34:41)

If you set ignoreUnusedDeps to false in the federation.config.js files, the build works as expected.

> ng build
 INFO  Building federation artefacts
 INFO  Preparing shared npm packages for the platform browser
 NOTE  This only needs to be done once, as results are cached
 NOTE  Skip packages you don't want to share in your federation config
Initial chunk files   | Names         |  Raw size | Estimated transfer size
polyfills-G7GBCUTJ.js | polyfills     |  36.72 kB |                11.96 kB
main-IX3NDLRZ.js      | main          |   2.81 kB |                 1.19 kB
chunk-2NFLSA4Y.js     | -             | 449 bytes |               449 bytes
styles-5INURTSO.css   | styles        |   0 bytes |                 0 bytes

                      | Initial total |  39.98 kB |                13.60 kB

Lazy chunk files      | Names         |  Raw size | Estimated transfer size
chunk-OS7HOA66.js     | bootstrap     |  20.19 kB |                 5.31 kB

Application bundle generation complete. [1.351 seconds] - 2025-12-31T19:45:07.894Z

Expected behavior

The build would succeed with this folder and project structure with ignoredUnusedDeps set to true.

Versions of Native/Module Federation, Angular, Node, Browser, and operating system

Native Federation: 21.0.3
Angular: 21.0.6
Node: 24.11.1
Browser: N/A
Operation system: Windows 11

Other information

This structure worked with module federation.

I understand that is partially a result of our folder structure, with each project having it's own workspace, but we kind of have to do it this way due to tooling and it's a common way to setup projects with the angular CLI.

This isn't urgent, as the workaround is to disable ignoreUnusedDeps but it's a nice feature that would be nice to use in our application since we use localization.

I would be willing to submit a PR to fix this issue

• Yes
• No

[Aukevanoost]

Hi!

So I did some digging, and, as you said yes the issue is regarding the isolation of your projects! But I'd say, why go for this setup at all? What I see is that most people choose for:

1. A monorepo setup, where the benefit is that you only have 1 place where you have to manage your dependencies and you can easily share code. Loads of enterprise tools like Nx help with the cleanup here, or you can rock your own monorepo setup with workspaces.
2. A polyrepo setup where all teams manage their own confined space and aren't dependent on other teams with stuff like merge conflicts or breaking eachother's code.

Now, I know this setup is simplified, but imho you have the worst of both worlds, and almost none of the benefits. However to solve the issue in this setup, I'd recommend release your library separately and download it as node_module.

it's a common way to setup projects with the angular CLI.

While you are correct, Angular supports workspaces with a single Angular.json and package.json. That setup will probably solve this issue.

@rainerhahnekamp Sorry to bug you with this but it's a Sheriff matter and I'm curious of your take on this! It happens here because it's an external module but not considered by TS (probably because it's not in the node_modules). Is what's happening here desired behavior?
Line where the error is happening: https://github.com/softarc-consulting/sheriff/blob/33a7db4e6d7b5c065d580a626b420973ce5c0955/packages/core/src/lib/file-info/traverse-filesystem.ts#L79

[jaxcksn]

So the key context that I left out for this repo is that each top-level folder is intended to be an independently buildable/deployable service that’s consumed by the shell host. Each service includes its own Angular client plus a BFF that hosts the microfrontend as an SPA.

In that model, the separate angular.json files are there to keep the service as the unit of build/runtime config. A single Angular workspace could be made to work, but it would centralize build config into one giant angular.json (we have like 15 remotes), and it would fight the fact that our deployment boundary is “service + BFF”, not “one frontend app”.

From what I can tell, the reason that this is a monorepo instead of polyrepo is simply that we use pnpm, and the catalogs help prevent version skew (and that having potentially 15 PRs per ticket feels a bit bad to keep track of).

---

We'll try consuming the shared library as a node module, and see if that helps. The big thing the team wants to keep is live reloading of our shell when the shared library changes.

[Aukevanoost]

Right! I get you. But with this level of isolation, why not go for a polyrepo setup?

With this setup, are you able to have live reload? If not you can alternatively check if you can use overrides with pnpm. I use them to reroute the library to my dev environment.

I'll see if i can find the issue where I explained how that works

Edit: #988 (comment)

I don't think having 15 remotes is inherently a bad thing with a monorepo setup. The only extra challenge is how you decouple your codebases enough that they have minimal interference, that does include shared libraries. Especially when you have multiple teams working on the codebase.

[jaxcksn]

I honestly think the decision was made just to avoid the pain of having 15 pull requests for a single ticket if the shared library changes. There's also a CI component that plays into it and the coordination of releases and canary artifacts. We're a single team for this application so the isolation doesn't provide much benefit either.

We have another product that uses a polyrepo (without federation), and the coordination there is a lot more work, especially when we do security and dependency related tasks. But the ideation behind the structure in this issue predates me by a couple years so that's the extent I know about the justification.

---

With our current setup, which uses module federation, changing a file in /shared causes the remotes and host to reload. I just tested it with my branch for the native federation migration, and it seems like the reloading isn't working now when I change shared so I'll have to look into that one.

I would still expect ignoreUnusedDeps not to be the condition that causes this error to surface. In my mind, if the workspace setup with path-mapping is incompatible, it should throw that "is outside of root" error for both true and false.

[rainerhahnekamp]

@Aukevanoost

Sorry to bug you with this but it's a Sheriff matter and I'm curious of your take on this! It happens here because it's an external module but not considered by TS (probably because it's not in the node_modules). Is what's happening here desired behavior?

That is a security measure, as you are effectively importing from another project which could have its own Sheriff configuration.

This is the first time someone has made this kind of request. Of course, we could consider removing the restriction, but I am concerned we might be opening a Pandora's box by doing so.