Ask HN: Is my repository analysis framework a good idea?

I've had a thought for a small to medium sized open source project and wanted to run it by HN for validation.

There's been a few times I've wanted to ask questions about the repositories at use in my workplace:

- what's the chain of dependencies?

- who uses v1.2 of the Foo library?

- which dependencies are common? Which ones would hurt us most if they had a CVE?

- are there certain kinds of dependencies that are quite fragmented? e.g. six different datetime libraries in use

- which files seem to cause the most contention in code review?

- which files require the most edits?

- which repositories listen to which SNS topics?

Et cetera

My idea was a package of helpers for traversing e.g. the repositories under a GitHub organisation, visiting certain files (e.g. package.json. requirements.txt, CloudFormation configs) and building up arbitrary graphs and categories.

Then what I could do is write a simple program calling my framework to e.g. create a graph visualisation of uses of internal library X

My main usecase would be JavaScript / TypeScript applications, so possibly I could even support using TSC to resolve uses of a symbol, e.g. to answer questions like "Who uses this legacy React component?"

I wonder how useful this could be - especially compared to existing approaches - and which features would be most valuable.

I'd also be really open to hearing ideas about the design I could use, ways to store or query the graphs built.

Broadly, what I'd like to know is: does this sound like a useful project?