Emerge is a browser-based interactive codebase and dependency visualization tool for many different programming languages. It supports some basic code quality and graph metrics and provides a simple and intuitive way to explore and analyze a codebase by using graph structures.
MIT License
818
stars
49
forks
source link
Dependency graph shows nonexistent dependencies in Go #47
Describe the bug
In a Go codebase, the file result dependency graph shows each .go file as depending on all .go files inside each of its imported modules, instead of only the ones with exported members used in the given file.
Describe your environment
Ubuntu 23.04?
Python 3.11.4
Google Chrome Version 115.0.5790.170 (Official Build) (64-bit)
Private repo
Here is an example output with of the program with debug (-d) flag enabled:
...
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile1.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile2_test.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile3.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile1_test.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile2.go
...
Only project/pkg/somepkg/gofile1.go contains exported members that are used in the file being processed, but all files under project/pkg/somepkg are added as dependencies.
To Reproduce
Steps to reproduce the behavior:
Create a config with at least dependency_graph and louvain_modularity scans enabled
Run the tool, go to the generated HTML
Open the file result dependency graph
See nonexistent dependencies between some nodes
Expected behavior
I'd expect only project/pkg/somepkg/gofile1.go to be added as a dependency and to see this reflected in the visualization.
Additional context
This issue is more evident in projects with many .go files under the same packages.
Given in Go you import by package, and not by file, it may be tricky to accurately represent dependencies between files. The Go standard library provides the go/parser and go/token packages, which can be used to parse Go files and analyze their abstract syntax trees (AST). That could be helpful, but I don't know how could it fit in this Python tool.
Describe the bug In a Go codebase, the file result dependency graph shows each
.go
file as depending on all.go
files inside each of its imported modules, instead of only the ones with exported members used in the given file.Describe your environment
Here is an example output with of the program with debug (
-d
) flag enabled:Only
project/pkg/somepkg/gofile1.go
contains exported members that are used in the file being processed, but all files underproject/pkg/somepkg
are added as dependencies.To Reproduce Steps to reproduce the behavior:
dependency_graph
andlouvain_modularity
scans enabledExpected behavior I'd expect only
project/pkg/somepkg/gofile1.go
to be added as a dependency and to see this reflected in the visualization.Additional context This issue is more evident in projects with many
.go
files under the same packages. Given in Go you import by package, and not by file, it may be tricky to accurately represent dependencies between files. The Go standard library provides thego/parser
andgo/token
packages, which can be used to parse Go files and analyze their abstract syntax trees (AST). That could be helpful, but I don't know how could it fit in this Python tool.