Repository navigation
Conversation
…entry points in use-library-builder The migration discovers secondary entry points by walking the library's root directory. For a library at the workspace root, this includes the directories of the other projects, so their ng-packagr configurations are added to the root library's `exports` and deleted before those libraries are migrated. Skip the root directories of other workspace projects while discovering secondary entry points. A new spec fails without this change.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the use-library-builder migration schematic to prevent treating nested workspace projects (such as libraries of a workspace root library) as secondary entry points. It achieves this by collecting the normalized root directories of all workspace projects and skipping them during the secondary entry point discovery process. A corresponding unit test has been added to verify this behavior. I have no feedback to provide as there are no review comments and the implementation is correct and well-tested.
|
Thank you for the pull request. Closing this as invalid because ngPackagr itself discovers secondary entry points by globbing from the primary configuration directory without awareness of angular.json project roots, so having a separate library project nested inside a root library is not a valid setup. |
The migration discovers secondary entry points by walking the library's root directory. For a library at the workspace root, this includes the directories of the other projects, so their ng-packagr configurations are added to the root library's
exportsand deleted before those libraries are migrated.Skip the root directories of other workspace projects while discovering secondary entry points. A new spec fails without this change.