[FEATURE] Visually isolate node of interest

[lonix1]

I was excited to find this tool - it is quite helpful. Thanks for making it.

Is your feature request related to a problem? Please describe.
In a large workspace with many projects, what I see is many blue nodes and blue edges. When I click on a node, it and its edges are made bold. Although very useful, it's hard to use.

Describe the solution you'd like
It would be nice to have a way to isolate a node. Some ideas when clicking a node:

1. it and its edges become bold as usual, but all other nodes and unrelated edges are muted (grey)
2. incoming edges are one colour and outgoing edges are another
3. best: both 1 and 2 simultaneously

Hope you'll consider it, and thank you!

[madushans]

Sorry for the late reply. Yes this sounds like a good idea. I'm looking at changing the html display altogether to something that allows a bit more customizability in a easier way. I'll take this into consideration.

[lonix1]

You might want to look at the way they do it in NUKE. I'm not saying it's better, just interesting and different - might provide you some nice ideas.

[tobyash86]

Very good idea for a tool, but @madushans is right - in the case of big solutions, it is not usable at all.

The nature of dependencies is a single-direction graph (in theory there should be no cycles, but I have seen some projects that do not follow this principle). Please consider adding the IncludeFolders option as it will be much more useful than excluding hundreds of folders users do not want to see. Alternatively consider something like expandable tree view where nodes are expandable as well.

[lonix1]

@tobyash86 Why am I wrong? I've used a large solution in NUKE and it's very helpful - check it for yourself, it's impressive.

[tobyash86]

I have tried it on a solution with 270+ projects and the HTML is very hard to read in such cases. Bold connectors do not help as well. I had to analyze dependencies and create my own dependency graph manually. I am not saying you're wrong, just that there are cases when it is not a suitable solution.

EDIT: The HTML looked like a "cloud" of projects and connections between them, but there were so many of them that it was unreadable.

[lonix1]

So what I'm proposing would work for most people, not for those with 270+ projects.

[madushans]

Yea there's a sweet spot where dependensee really shines.

If you only have a handful of projects, may be you don't need a visualizer as it may not be too hard to keep the structure in your head. (Though I can see teams may like to have the diagram in order to reason, or to explain it to the new joiners.)

If you have like a 100 or more projects, first... what u doin? get some help. But also changes like #23 and #26 can reduce the number of projects and packages.

Currently my overall thinking is that if you have 100s of projects, you probably should be looking at a smaller scope. May be a solution file that has a subset of the projects, or split the codebase to smaller pieces. Its questionable what one would be trying to achieve by seeing the dependencies of 100s of projects at once.

Better solution is likely to be able to group projects logically. I don't know how exactly to achieve this right now. But this could provide a more friendly and less overwhelming result than showing a diagram which only serves to show 'yep, there's a lotta stuff'.

How to group them is a good question. There are a few options I can think of.

• If there are multiple solutions may be they're logical
  • this does assume a given project is not in multiple solution files.
• File structure.
  • While some projects do have projects grouped this way, usually they're solution folders and not physical folders. So will have to have the option to use those or physical folders.
• Project name/namespace
  • Likely the easiest one using prefix and/or suffix, though could also end up grouping things unexpectedly if dependensee gets it wrong.

[madushans]

Another way is to allow the project to have some description of groups. Does require the project authors have some json file i na known place DependenSee can read, like at the root folder. But this will be more explicit and allow more control over what to expect like groups, what to include or exclude .etc.

I do want DependenSee to work out of the box for atleast most of the cases. So this should atleast be optional.

[mikhail-barg]

I'd like to add my 2 cents.

If you have like a 100 or more projects, first... what u doin? get some help.

Actually, that's what happens when you have a monorepo, which is a case for some companies (big and small) and it has it's benefits. And it's kinda my case.

And for it I do use DependenSee, and I'd like to thank you for the tool! It does help me to get insights into projects inter-dependency, find weird references, etc.

So I'd advocate for supporting huge solutions. I mean, if you have a couple of projects in your solution, it's not than hard to get the dependency graph manually anyway. And for huge solutions DependenSee is a life-saver!

[jeremy-allocate]

I have a local change that can produce a slice through a solution based on giving it a single project directory that has no project-containing directories under it, and then chasing all the project dependencies of that project recursively until they've all been found. We have a monorepo with multiple APIs, but with this fix I was able to see just focus down on a single API and all of it's dependencies's dependencies all the way up to the root of the dependency graph. OOTB when I limited it in this way I got a very limited graph that only showed that projects immediate dependencies that were in that one project file, which wasn't what I wanted as I can get that from just looking at that was csproj in a text editor. I'll try to get a PR together around it and we can see what @madushans thinks.

[jeremy-allocate]

OK, the PR for this is posted too: #38. Let me know if you have any questions @madushans. If you're comfortable running this in vscode off a branch, this change is available on my fork at https://github.com/jeremy-allocate/DependenSee/tree/dev @mikhail-barg. Point the source directory at a single project directory within the large solution and use the -ITDep flag to chase all of its dependencies recursively to the root and include them in the diagram. Feedback welcome.