Compilers/transpilers seem like a prime example. For example, imagine Typescript vX using utility-library-a, which itself is written in Typescript and has Typescript vY as a dev dependency.
You're right, that is a perfectly valid occurrence! However, I did not count dev- or peer- dependencies in cycles; only true-blue dependencies. So all the cycles I counter were either not of that type, or failing to use devDependencies -- which would also be unfortunate.
That's fair. Does npm have a way to declare build vs runtime dependencies? That would at least let you qualify that kind of thing (although only somewhat). (Sorry if this is a noob question; I'm interested in package managers, but I've never meaningfully worked with NPM specifically, so I don't know some of the local context.)
EDIT: Looks like that's devDependencies? So we can at least sometimes prune the runtime dependencies, which is nice.
EDIT2: Actually reading more I'm not sure devDependencies is quite that same, although it's similar.
Problem domains where you have tricky algorithms with weird edge cases, like complicated graph searches/traversals, computational geometry, linear algebra. You'll often compose your algorithms out of other algorithms, pulled in as dependencies. Then your algorithm can be used by an upstream dependency if it resolves some weird edge case.
Things like first class functions or programming with combinators naturally leads to those kinds of dependency graphs, it's basically a form of recursion.
