- Local extensions on Windows are not symlinks but files whose contents is the path to the local extension directory
- Local extensions elsewhere are symlinks
- this was something I did in the original implementation of this improved extension update notification logic
- discovering other parts of the extension manager code that were working with non-prefixed extension names motivated a different approach
- the extension manager code that requires the extension be prefixed has been enhanced to use the centralized ensurePrefixed() logic, making the need for this on the extension unnecessary
- extension manager has been made responsible for extension update directory information
- extension manager has been enhanced to ensure that previously left extension update metadata is deleted before installing an extension
- extension manager has been enhanced to ensure that extension update metadata is deleted when extension is being removed
- refactored extension command tests for manager change, ensuring previous and expected states along with returned release info
- refactored extension manager tests for ensuring previous extension update entries are removed before installing extension
- created extension manager test for installing local extension
- centralized logic for checking and ensuring extension name is "gh-" prefixed
First pass at implementing basic test around extension state checking behavior, wanting to discus with team about level of testing to perform and whether this is really the right place.
This commit allows for stubbing/mocking the function used for checking update release info. Additionally, this does a minor refactor moving from non-blocking to blocking channel.
This commit is a bit of refactoring to bring the extension update checking logic up to par with what is done with `gh` including creation of state file per extension and listening to env vars for disabling version checking.
This work is not complete as it does not address necessary test changes.
Addressing feedback from extension author demonstration about a noticable pause waiting for extension execution to complete due to amount of time waiting on channel.
This commit expands upon the previous work by creating tests around extension command execution and how various extension update scenarios are handled.
Along the way, the logic handling formatting update messaging has been switched to use `ColorScheme` in order to honor color behavior flags.
Building on logic from the `gh ext list` for retrieving and assessing extension release information, this commit enhances the logic around invoking extensions to check for new releases.
Using the same user experience from checking `gh` version, this should only output information when the extension is used and gives the user information on how to upgrade depending on the type of extension and whether it is pinned or not.
```shell
andrewfeller@Andrews-MacBook-Pro cli % gh ext install dlvhdr/gh-dash --pin v4.6.0
✓ Installed extension dlvhdr/gh-dash
✓ Pinned extension at v4.6.0
andrewfeller@Andrews-MacBook-Pro cli % ./bin/gh dash
A new release of dash is available: 4.6.0 → 4.7.0
To upgrade, run: gh extension upgrade dash --force
https://github.com/dlvhdr/gh-dash
```
