create graph for kotlin multiplatform modules relations

[aminshojaei13]

⚠️ Is your feature request related to a problem? Please describe

when I use your module graph in my modular multiplatform app, I can't see my sub-module (common, android, ios) and their relations with other sub-modules and just see parent module relations.

💡 Describe the solution you'd like

I get this graph :

%%{
  init: {
    'theme': 'neutral'
  }
}%%

graph TB
  :composeApp --> :x
  :composeApp --> :y

Loading

but I want to create graph like this :

%%{
  init: {
    'theme': 'neutral'
  }
}%%


graph TB
  :android --> :x:android
  :common --> :x:common
  :ios --> :x:ios
  :ios --> :common
  :android --> :common
  subgraph composeApp
   :common 
   :android
   :ios
  end
  :x:android --> :x:common
  :x:ios --> :x:common
  subgraph module x
   :x:android
   :x:common 
   :x:ios
  end
  :y:android --> :y:common
  :y:ios --> :y:common
  :common --> :y:common
  subgraph module y
   :y:android
   :y:common 
   :y:ios
  end 

Loading

🤚 Do you want to develop this feature yourself?

• Yes
• No

[iurysza]

Hey there!

So the thing is, those aren't all modules. For instance, in your example above, ios, android, and common are source sets, not modules. The only modules are composeApp, xand y.

That's Gradle terminology. But I get your point, and it's an interesting and useful feature.
There's probably a way to make this work, but I'll need to investigate.

Thanks for the suggestion.

[jyrimatti]

Hi,

thanks for a useful, working and easy to use plugin!

I believe I may have the same problem. We have modularized part of our application stack as separate Gradle sourceSets/configurations, which are then assembled into artifacts to be used as dependencies like this:

implementation project(path: ':commonstuff', configuration: 'security')

where Gradle project commonstuff contains a sourceset/configuration/artifact called security.

Well, it might be that the "supported" Gradle way to modularized would be to split the stuff into separate nested sub-projects of commonstuff, but it would still be awesome if this plugin could support our method.

What do you think, does it complicate the implementation too much to kind of include the referenced configuration with the referenced project?