Mind you, adding dependencies does not imply increasing build artefact sizes. Suppose A depends on B and C, and B and C contain similar functionality, then coll

Mind you, adding dependencies does not imply increasing build artefact sizes. Suppose A depends on B and C, and B and C contain similar functionality, then collaborate to extract that into D, so that A ends up with one more dependency, but less code net. (This is the theory of the tiny package philosophy widely found in npm. But in practice, they often seem to clog things up awfully with runtime type checking and the likes, or just adding a pointless level of indirection, so that they make things worse. But the underlying idea is sound.) —⁂— For the rest, most of the pieces already exist and are not particularly difficult to put together, though a more polished presentation of a holistic experience (if you’ll pardon the expression) could be desirable. For suggesting dependencies to remove and flagging undesirable dependencies, that’s entirely a data problem: you want another audit/code review/advisory database, really. (You could take it further and identify automatic code translations, but that’d be quite a bit more work, though again the bones that you need generally already exist.) For pointing out dependency costs: such metric monitoring is already widely used, especially in larger projects that want to catch regressions immediately.