Dev Discussion

[PabloLION]

While going through all the current issues, I see some related issues and I'm trying to categorize them. This issue is created to discuss the priority of each versions and make some plan (or use GitHub Projects), and how do we achieve the goals, including the design pattern change, etc. (or use GitHub Discussions)

[PabloLION]

Refactor

• There's a TS version FauxFaux/fadge from #275

API

• VSCode Extension, covering #187

Visualization

After seeing these problems, I think we should maybe make the dependency graph "reactive" : the nodes expand / collapse on click. But this seems a bit off-topic of madge. An alternative is to make / use a new package to print this "reactive" graph and integrate this package into madge. What do you think? @vikingair @kamiazya @pahen

• This is actually the same idea as PR #333
• group #181, #202 , https://github.com/joebowbeer/repdeps
• filtering exclude some (dynamic) import #344 or files #280 . This might be solved by #282
• subgraph #254 , #309
• expand / collapse node #289

Docker

• 287

• 302

[PabloLION]

I spent many hours labelling all the issues. I wish there were a bot to do this possibly with ChatGPT. Not sure what should we do next, I'm thinking about

• refactor the repo, or adopt something from fadge, or ignore this step
• fix bugs
• and then update the visualization part in v6.2 or possibly v7.0 (depend on how big is the change), as it's be requested a lot in the issues. Also rediagram might help in this process

[vikingair]

Thanks for your effort @PabloLION

I still had no chance to play around with the visualization stuff, so can't tell what's possible and what's not. If we require more flexibility and also aim to make the dependencies more lightweight, does this mean we would replace graphviz?

I'd like if we first clean up the open PRs, as a good sign that code contribution is high valued. Doesn't mean we should merge them all, but closing with good reason would also be nice.

[PabloLION]

Agreed. I'll work on those PRs now. Great suggestion!

[vikingair]

Another thing, I'd like to share, is what I'm using Madge for and what is important to me.

I've introduced Madge in dozens of projects as CI lint target to prevent engineers from introducing circular dependencies early on. In the beginnings of Webpack circular dependencies could cause the build of an application to fail and these kind of issues where very hard to detect and to fix. That's when I stumbled over Madge and with its visualization features (primarily on the console), it was possible to fix the root cause. Also, I've found that preventing circular dependencies produces more clear overall code structure.

However, as of now these kind of issues are very easy to fix, because I made sure they don't bypass any CI checks. So I don't really depend on the graphviz features even though they are really nice.

On the other hand, I think it would be nice if it would also support Vue and Svelte files for dependency resolution, but it seems to be very tricky because dependency-tree doesn't seem to support those.

Btw. if you know surprisingly a good working alternative covering my needs, I'd appreciate your opinion. I tried already fadge and eslint-plugin-import with import/no-cycle options. Both were not catching simple circular deps I've introduced whereas madge was able to, so they seem bad alternatives.

[kamiazya]

We have started merging PRs and have created milestones for 6.1.0.

Please tie them to what you think is needed before the release.

[kamiazya]

I had talked about volunteering until the end of March, but my work is starting to get busy and I may not be able to guarantee enough time to be involved in this project after that.

I may be able to work on releases and other specific tasks, so please contact me if needed.