in your angular app that depends on your local library, set projects.projectName.architect.build.options.preserveSymlinks with true in angular.json will prevent the angular cli from updating linked local library

This happens when @NgModule() is resolved from a different node_modules location.

Given this configuration, we can use my-lib from my-app directly without building my-lib:

# project directory structure
/
  /my-app
    /node_modules
    /projects
  /my-lib
    /node_modules
    /projects

# my-app's tsconfig.json:
    "paths": {
      "my-lib": [
        "../my-lib/projects/my-lib/src/public-api"
      ]
    }

As @mhevery highlighted, the error indicates that somehow there are two copies of Ivy in there. This was due to TypeScript’s module resolution approach - it looks for node_modules by traversing up the directory of file being compiled.

To fix this, I tell Typescript where to find Angular packages by using:

    "paths": {
      "@angular/*": [
        "./node_modules/@angular/*"
      ],
      "my-lib": [
        "../my-lib/projects/my-lib/src/public-api"
      ]
    }

Initial test seems to be working. Hope this helps.

Also, I think this approach does not depend on preserveSymlinks or "enableIvy": false.

Specifying path to angular packages as @kctang mentioned was enough for me to fix the error, thank you for that. I just wanna point out that the path belongs in the compilerOptions section of app’s tsconfig.json file.

// app's tsconfig.json
{
  ...
  "compilerOptions": {
    ...
    "paths": {
      "@angular/*": [
        "./node_modules/@angular/*"
      ]
    }
  }
}

For now I guess I’ll have to create a little schematic for my co-workers to spare them the trouble, but I really hope this gets fixed soon tho.

Edit: I should probably read documentation twice next time.

Edit2: Oh and specifying path to lib’s source code to skip building is actually really useful. Big ups to @kctang for that as well!

Ok, this issue only happens when you link the library (or use file:... in your package.json).

When you build the library with ng build my-lib --prod and manually copy the dist/my-lib into node_modules/my-lib (thus not creating a symlink) the ng serve is not throwing an error and everything works.

If you use npm link, you can see that the original library folder (dist/my-lib) gets changed on ng serve, also the package.json will be modified, for example this is added:

  "scripts": {
    "prepublishOnly": "node --eval \"console.error('ERROR: Trying to publish a package that has been compiled by NGCC. This is not allowed.\\nPlease delete and rebuild the package, without compiling with NGCC, before attempting to publish.\\nNote that NGCC may have been run by importing this package into another project that is being built with Ivy enabled.\\n')\" && exit 1"
  }

The problem lies here somewhere. If you publish the package to npm (or github), this won’t be an issue. I think if you create a read-only symlink to my-lib, this will work as it will not modify the original package?

In summary: npm link with custom libraries is currently broken (I think only with 9.x.x?). When ng serve is being run, the linked package gets modified and thus broken.

I have the same issue. I have different workspaces for library and app.

I’ve been facing the same issue in a recent project… In this case though

"preserveSymlinks": true,
"paths": {
  "@angular/*": ["./node_modules/@angular/*"]
}

Doesn’t help!

The difference with the other projects, where it worked is that in this case we are working with angular 17 with the new build system and vite

Does this now need a different workaround?

@00guille I got it working by adding this option to tsconfig.json of both the library repository and the main app repository:

  "angularCompilerOptions": {
    "enableIvy": false
  }

I haven’t tested all the possible configurations (like using Ivy in the main App and not using it in the library or vice versa).

I can now link the dependency locally and it works. Hope this helps for now.

it worked! but the idea is to be able to use ivy with the benefits that it carries

I hit the same issue trying to have a multi project setup with an ionic project and an angular project trying to share a common library.

this answer solved the problem for me but I was wondering if it has any downsides to directly referencing the library like " “…/my-lib/projects/my-lib/src/public-api”" rather than looking for the version in the dist folder.

Because this solves a couple of issue for me which I find very useful,

1. not able to find all references from the library
2. “go to definition” you will end up in the dist folder than the actual code.

This happens when @NgModule() is resolved from a different node_modules location.

Given this configuration, we can use my-lib from my-app directly without building my-lib:

# project directory structure
/
  /my-app
    /node_modules
    /projects
  /my-lib
    /node_modules
    /projects

# my-app's tsconfig.json:
    "paths": {
      "my-lib": [
        "../my-lib/projects/my-lib/src/public-api"
      ]
    }

As @mhevery highlighted, the error indicates that somehow there are two copies of Ivy in there. This was due to TypeScript’s module resolution approach - it looks for node_modules by traversing up the directory of file being compiled.

To fix this, I tell Typescript where to find Angular packages by using:

    "paths": {
      "@angular/*": [
        "./node_modules/@angular/*"
      ],
      "my-lib": [
        "../my-lib/projects/my-lib/src/public-api"
      ]
    }

Initial test seems to be working. Hope this helps.

Also, I think this approach does not depend on preserveSymlinks or "enableIvy": false.

Specifying path to angular packages as @kctang mentioned was enough for me to fix the error, thank you for that. I just wanna point out that the path belongs in the compilerOptions section of app’s tsconfig.json file.

// app's tsconfig.json
{
  ...
  "compilerOptions": {
    ...
    "paths": {
      "@angular/*": [
        "./node_modules/@angular/*"
      ]
    }
  }
}

For now I guess I’ll have to create a little schematic for my co-workers to spare them the trouble, but I really hope this gets fixed soon tho.

Edit: I should probably read documentation twice next time.

Edit2: Oh and specifying path to lib’s source code to skip building is actually really useful. Big ups to @kctang for that as well!

this actually fixed my same issue

I found out that the problem was that I’m using the --prod option in my library build command the solution was to

• remove the --prod option
• set "preserveSymlinks": true and suggested here
• and enable Ivy "enableIvy": true