This issue serves to capture the completion of the work @mislav started in #909 ( #909 (comment) ) to structure our commands in isolated units instead of grouped together in a big soup of global state.
This work allows us to complete #759
Original issue body below, which captures the spirit of these improvements.
Describe the feature or problem you’d like to solve
Looking under the the command package of the project, it could have some better organization to help address a few problems that may come up while trying to maintain the CLI:
- It makes it simpler to find where all source associated with a particular subcommand is (e.g. all the code for
gh pr should be isolated from other source
- It will help to eliminate dependencies that exist currently between subcommands. As of now, functions are defined in one subcommand (e.g.
displayUrl in issue.go and used in pr/repo source. It makes it hard to keep track where functions are defined/how changes to it will effect other subcommands.
- It can help make it easier for contributors to understand the command structure of the CLI. Cobra structure allows subcommands to be imported into
root.go and added directly to the root command and this same structure can be added at the subcommand level as well by adding all those commands as opposed to using an init() function.
Proposed solution
Create separate packages for subcommands/helper functions:
pr - all source for gh pr
issue - all source for gh issue
repo - all source for gh repo
completion - all source for gh completion
version - all source for gh version
common - all shared functions that are used across all commands (e.g. contextForCommand, determineBaseRepo). Should probably have a better name than something non specific like util, helper, or common.
Remove init() from root.go, import all subcommand packages to root.go, and add subcommands directly to RootCmd. Apply this same approach at the subcommand level.
How will it benefit CLI and its users?
It
will help bring better organization to the project and make it easier for people to contribute back to.
Additional context
Due to issues around circular dependencies, this may take a bit of thought, which is why I think it would make sense to remove version command logic from root.go/commonly used functions to their own package.
Thought process of structure in root.go:
import (
"github.com/cli/cli/command/issue"
"github.com/cli/cli/command/pr"
...
)
....
RootCmd.AddCommand(
issue.issueCmd(),
repo.repoCmd(),
pr.prCmd(),
version.versionCmd(),
completion.completionCmd(),
)
This issue serves to capture the completion of the work @mislav started in #909 ( #909 (comment) ) to structure our commands in isolated units instead of grouped together in a big soup of global state.
This work allows us to complete #759
Original issue body below, which captures the spirit of these improvements.
Describe the feature or problem you’d like to solve
Looking under the the
commandpackage of the project, it could have some better organization to help address a few problems that may come up while trying to maintain the CLI:gh prshould be isolated from other sourcedisplayUrlinissue.goand used inpr/reposource. It makes it hard to keep track where functions are defined/how changes to it will effect other subcommands.root.goand added directly to the root command and this same structure can be added at the subcommand level as well by adding all those commands as opposed to using aninit()function.Proposed solution
Create separate packages for subcommands/helper functions:
pr- all source forgh prissue- all source forgh issuerepo- all source forgh repocompletion- all source forgh completionversion- all source forgh versioncommon- all shared functions that are used across all commands (e.g.contextForCommand,determineBaseRepo). Should probably have a better name than something non specific likeutil,helper, orcommon.Remove
init()fromroot.go, import all subcommand packages toroot.go, and add subcommands directly toRootCmd. Apply this same approach at the subcommand level.How will it benefit CLI and its users?
It
will help bring better organization to the project and make it easier for people to contribute back to.
Additional context
Due to issues around circular dependencies, this may take a bit of thought, which is why I think it would make sense to remove version command logic from
root.go/commonly used functions to their own package.Thought process of structure in root.go: