Major code refactor and add detail command

[thehanimo]

• generateTable and getRepositories are now utility functions.
• fields and mappedFields are combined to:

  const fields = [
  { name: 'Repository', extract: (item) => item.nameWithOwner },
  ];

• detail command encloses list and options for now. (Can add more)
• branchProtection command does not work. (Query is incorrect. Can be fixed with another PR)
• branchProtection is repo specific. (One repo can have multiple branch protection rules. Need to discuss if it can be shown in detail command)
• pr-status is also repo specific. (Does not come under detail command)
• With this refactoring, commands only have fields and queries in them. Everything else is handled by utility functions.

[diananova]

the fields and mappedFields combination is great! The code looks good to me. I guess I can close my pr, cause you already kind of integrated it here.

[diananova]

@thehanimo hey maybe I could get rid of some fields that Jordan mentioned?

[thehanimo]

Yes that'd be awesome. Also maybe reply to the comments on what the properties really stand for? You can find it all here https://docs.github.com/en/graphql/reference/objects

[ljharb]

Note, I put "not sure" on purpose, if you think any of those fields do make sense to keep, please push back and help me understand why :-)

[diananova]

I wrote down my opinion on which fields can be removed, thinking from a maintainer's perspective and what info they would find useful.

It's important to remember the purpose of this tool: to find settings that are different from our "default" and to be able to change those settings easily.

NO:

• DiskUsage: I don't think we need this one.
• isDisabled: Returns whether or not this repository disabled. I looked this up online and I think this concerns a very specific case in which Github disables repos if an organization admin stops paying for private repos. I don't think it's relevant in our case.
• isEmpty: Returns whether or not this repository is empty. I don't think we need this one. Very rarely a maintainer's repo would be completely empty.
• isFork: I don't think we need this one. Knowing if a repo is a fork or not isn't useful/doesn't make a difference.
• inOrg: nope.
• isLocked: happens when a git lock file is generated. I don't think this is relevant to us.
• isMirror: not relevant.
• isTemplate: not relevant.
• isUserConfigurationRepository: not relevant. I didn't understand what a User Configuration repo is, and I think most users wouldn't know/care either.
• stars: not relevant.
• CustomOpenGraphImage: not relevant
• viewerCanAdminister: Indicates whether the viewer has admin permissions on this repository. I don't know if need this one if we already ViewerPermission. Seems redundant.
• viewerCanCreateProjects: not really useful. It would be useful to know if other people can create projects (what permissions does a user need to create projects? Would I want just anyone to be able to do that?)
• viewerCanSubscribe: not relevant
• viewerCanUpdateTopics: not relevant

YES:

• ViewerPermission: The users permission level on the repository. Values: ADMIN, READ, WRITE.. .
• isPrivate: as Jordan mentioned, we don't have to display it as another field, but we can use the lock emoji. So we still need this in the query.

COMMENTS:

• only collabs can edit the wiki: we weren't able to find this one in the repo object. Should look into it.

TODO:

• [x] merge mergeCommit, squashMerge, rebaseMerge into 1 field "merge strategies"

[diananova]

@thehanimo let me know what you think so I can go ahead and delete the irrelevant fields.

[ljharb]

@diananova your summary makes sense to me, thanks for enumerating it all!

[thehanimo]

@ljharb I've updated it all based on @diananova's comment. Couldn't find the "only collabs can edit wiki" metric in the GraphQL API.