I'll add an answer that extends the notion of using nx extensions (which I use for all my projects except quickee/stubs):
This assumes you have ng-packagr set up to build libs within the nx workspace.
Create your libs, etc. Let's say you have lib1, and lib2.
Now, say lib1 uses something from lib2.
- Build lib2
- npm link the build output of lib2, from the root of the repo.
- In lib1, import the assets you need from lib2 from the BUILT version, which
would be configured based on the output you configured for that lib...
...NOT the version in tsconfig.ts!!! You want whatever you
configured in the package.json of the linked lib in the "dest" property., which after linking, you should find in node_modules.
- build lib1
- profit!
This might sound a little odd, but if you think about it the sense is there. You're using the libs exactly the same way as if you were using them in an external app (well, not exactly the same, you're linking them, but that simulates the process of a package.json install).
Note that also, within the mono repo, you can just use relative imports across libs (again ignore the tsconfig path entries and just use relative pathing to grab files from other libs). It works, probably not technically correct but may save you some headaches.
I crashed right into this question in a big project, and it was mine to solve, I found both these methods satisfied the need, presented both to the team, and to me, was ok with whatever they said (apologies for declining to discuss the team's decision).
Note that I see no reason this wouldn't work in a non-nx-extensions setup. But I rarely work with them anywhere, a big part of what I do is evangelizing monorepo dev and, when confronted with Angular, NX is what I work with the team on.