Feature request
When running graphify on a large multi-repo corpus (10+ repos, 150+ communities), the community panel becomes a long undifferentiated list. It would be useful to group communities by theme or prefix so related communities are visually clustered in the sidebar.
Use case
Running graphify on a workspace with repos like SharedPackages, DocuMind, CampaignManager, etc. produces communities named:
- "Storybook Infrastructure"
- "Storybook Stories - Auth"
- "Storybook Stories - UI"
- "i18n + Localisation"
- "API Layer - DocuMind"
- "API Layer - CampaignManager"
It would be helpful to collapse these under group headers (e.g. "Storybook", "API Layer") so you can hide an entire theme with one click instead of toggling each community individually.
Possible approaches
- Prefix-based grouping — detect common prefixes in community labels (e.g. "Storybook *") and render a collapsible group header with a bulk hide/show toggle for the group
- Manual tagging — allow a
community_groups.json config file where the user maps community IDs to group names
- Automatic clustering — cluster community labels semantically (would require an extra LLM pass)
Approach 1 seems most practical with zero user config needed.
Benefit
Particularly valuable for large cross-repo graphs where storybook-static/ or similar build artifact communities dominate the list. Being able to hide the "Storybook" group entirely in one click would clean up the view significantly.
Environment
- graphifyy version: latest (pipx install)
- Corpus: ~350 files, 173 communities, 10 repos
Feature request
When running graphify on a large multi-repo corpus (10+ repos, 150+ communities), the community panel becomes a long undifferentiated list. It would be useful to group communities by theme or prefix so related communities are visually clustered in the sidebar.
Use case
Running graphify on a workspace with repos like
SharedPackages,DocuMind,CampaignManager, etc. produces communities named:It would be helpful to collapse these under group headers (e.g. "Storybook", "API Layer") so you can hide an entire theme with one click instead of toggling each community individually.
Possible approaches
community_groups.jsonconfig file where the user maps community IDs to group namesApproach 1 seems most practical with zero user config needed.
Benefit
Particularly valuable for large cross-repo graphs where
storybook-static/or similar build artifact communities dominate the list. Being able to hide the "Storybook" group entirely in one click would clean up the view significantly.Environment