In reviewing #3870 I came up with a pile of general extensions feedback; a bunch of this is likely already on a TODO list somewhere but I wanted to point it just in case.

breaking/urgent

bad local upgrade experience

Locally installed extensions are treated the same as remote extensions for upgrading. This means ugly error messaging if:

• a local extension isn't a git repo (which we allow installation of)
• a local extension is a git repo but has no remotes defined (even if it did, we should not be pulling local extension repos ever)

segfault when aliasing an extension

aliasing an extension makes it impossible to use the extension's full name

gh alias set e echo   # works
gh e hi                      # works
gh echo hi                # seg fault
gh alias delete e
gh echo hi                # works

UX concerns

silent removal

it would be nice if gh extensions remove foo printed a confirmation.

built-in shadowing - don't allow install

An extension that shadows a built-in (ie gh-pr) isn't called if it's installed...but it shouldn't be installable to begin with.

current:

gh extensions install vilmibm/gh-pr   # works

expected:

gh extensions install vilmibm/gh-pr
X extensions can't replace built-in commands

confusing extension argument in upgrade/remove

I wasn't sure what argument to provide for upgrade:

gh extensions upgrade gh-echo              # no
gh extensions upgrade vilmibm/gh-echo # no
gh extensions upgrade echo                   # yes

This confused me because in the output of list it's not really clear what the "identifier" is for an extension -- you have to use vilmibm/gh-echo to install, list shows both gh echo and vilmibm/gh-echo, but upgrade wants echo. I think the inputs to upgrade should be fuzzier and the output of list should drop gh (which is redundant) and bold echo to hint that you can refer to it for upgrade/removal as such.

It would be nice to support naming extensions in upgrade/remove in one of four ways:

• fully qualified github.com/vilmibm/gh-foo
• semi qualified vilmibm/gh-foo
• gh-foo
• extension name foo

built-in shadowing -- list callout

It's conceivable that someone might install gh-foo and in a later gh release we add an official foo command; in this case, the extensions list should highlight the fact that gh-foo is now uncallable and should be removed / replaced with a renamed version once it's available

local install callout in list

The path to locally installed extensions should be printed in list

document local install option

I know that the docs haven't been fully written yet, but wanted to mention the local install feature as a current glaring omission

Less urgent nice-to-have

gh extensions reset [--all]

It looks like it is very easy to end up with un-upgradable extensions given that upgrades are supposed to be fast-forward only. If a maintainer does any history rewriting then upgrade ceases to be possible, requiring a remove/install. A reset command that does the remove/install for you might be nice.

gh extensions view [-w]

Similar to repo view but works for local extensions, also.

summary export for commands

This might not be crucial for launch, but it would be nice to allow extensions to label themselves with a summary so in the output of gh help they are a little less opaque/barren:

EXTENSION COMMANDS
  echo
  foo
  pr