Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Restructure commands in isolated units #770

@danielhelfand

Description

@danielhelfand

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:

  1. 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
  2. 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.
  3. 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(),
)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementa request to improve CLI

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions