dep is the "official?" vendor tool, and should be ready to use.

The configuraions for loader commands is highly dupicated. Use common type for each and allow specifying or overriding uncommon parts.

If there is an error, the application should return a non-0 status. Determine how to do this with sfp13/Cobra.

The imports and globals commands have some common flags. Investigate using a common parent command to process these, or find other solution to redundancy.

The globals and imports commands traverse the entire AST tree, which may not be what the user is interested in. For example, the user may not care what the stdlib imports.

Suggested traversal levels:

• shallow - just the specified package
• local - just packages that have the same root (i.e., github.com/object88)
• deep - all non-stdlib packages
• complete - every package, regardless of source

Might also be interesting to add a numeric depth control, stopping the traversal after N steps.

Using the --verbose flag along with --astDepth c can sporadically cause the app to crash, presumably due to issues with package depth.

This is a problem for main, which can be in any directory.

% ./bin/cprofile imports test/globals/main.go 

pkgName: 'github.com/object88/cprofile/test/globals/main.go'
Got error: Failed to locate package 'github.com/object88/cprofile/test/globals/main.go'

When showing list of imports, vendor packages show up as a vendored path, instead of their natural package names:

Actual:

...
flag
fmt
github.com/object88/cprofile
github.com/object88/cprofile/cmd
github.com/object88/cprofile/main
github.com/object88/cprofile/vendor/github.com/spf13/cobra
github.com/object88/cprofile/vendor/github.com/spf13/pflag
go/ast
go/build
...

Expected:

...
lag
fmt
github.com/object88/cprofile
github.com/object88/cprofile/cmd
github.com/object88/cprofile/main
github.com/spf13/cobra
github.com/spf13/pflag
go/ast
go/build
...

Currently, logging is all-on, all-the-time (except for version command). Determine some appropriate logging levels and apply.

The current code expects to follow imports from a particular package, but this is not in line with the needs of consuming a project workspace. For example, if a project is open in an IDE, the program entry point will not necessarily align the root of the workspace:
~/go/src/github.com/foo/myProject/main
vs
~/go/src/github.com/foo/myProject
If myProject is the root for cprofile, it will not ingest main if that is where func main lives, due to Go's circular package reference avoidance.

If this library is going to be useful in an IDE that doesn't implicitly understand the ideal package starting point.

Document the expected use cases and program output with regard to stderr and stdout.