How granular the libs should be?

[J-Huang]

In the documentation, it says:

The more granular your libraries are, the more effective nx affected and Nx's computation cache will be.

It makes perfect sense since lib is the smallest unit in nx world.
Does that mean it recommends to separate tests from the lib as another lib? I would imagine most users, including us, colocate tests with the real code in the same lib. If a test imports a module, which has not been imported by the lib itself, it would trigger unnecessary tests. The following demo graph shows the idea.

If a library is instead considered a lib and a lib-tests (on the right side of the demo graph), change graph behavior is clearly desirable. Since this could be an issue that many users encounter, wondering if there is already a recommended pattern.

• Are there formal patterns that exist?
• Does NX apply such a pattern, even if informally? Why/why-not?
• A broader question is, should lib be as slim as possible, even if that means there will be thousands of libs?

cc: @vsavkin @cdaringe

[cdaringe]

I suppose I drew the arrow backwards from Lib B -> Lib B __tests__ in the right diagram :)