from the document:

This is actually one of the simpler ones. If A declares a private dependency on Z, but use of A’s interface by a client C induces a dependency on symbols from Z, then A’s declaration of the Z dependency should be promoted from private to public. Such a transformation is always safe: no edges are removed, and no other nodes will have their current dependency set reduced.

 

There is a subtle angle to this one (of course!): it is possible that use of A’s interface induces symbol dependencies on Z in C not because of the direct use of Z in A’s interface, but because A induces the use of symbols from B, and use of those symbols from B induces the use of symbols from Z. If all of the induced uses of Z in consumers of the A interface can be explained away by other should-be-public dependencies of A (like B), then it makes no difference if Z is public or private in A: B will need to be public in A, and Z will need to be public in B. In such situations, it seems best that if A really does make direct use of Z internally, that it be declared a private library dependency despite the fact that B will drive it through A as public to A’s clients. Otherwise, if B later changed such that it no longer induced a Z dependency on clients of A’s interface, Z would suddenly become flagged as public-should-be-private in A.

 

Given that the transformation suggested by the linter is safe and the conditions reasonably easy to understand, it is probably a good candidate for implementation early in the project.