gh
gh copied to clipboard
node-gh
Improve .gh.json updates for new versions
What about having a .gh.json file with the default configuration that will be updated on every node-gh update and another .gh-username.json that overrides the default configuration?
If you register aliases using the gh alias command, then it saves on .gh-username.json file. If you want to override a certain hook, then create the keys on .gh-username.json and so on.
That might be the same of us leaving the ~/.gh.json empty when first created, and the user adds only what he wants, then it overwrites the keys from the original one.
This can still cause issues, since we are going to merge the two objects - the user and the template - if the user overwrites a key like "hooks" it will replace all the original hooks, so he will never get the updates, keeping the same problem. That's also true for the approach of .gh-username.json.
We could do a smarter merge of the objects though. What do you think?
Hi guys, from the point of view of using the library not as a standalone cli program but as a nodejs library, it would be cool if those configurations could be also set/merged programatically.
One option could be something like base.setConfig that could receive a sparse json object to merge with the users default.
Another possibility would be a per-setting method like base.setSetting('hooks.issue.close.before', []) or base.setSetting('signature', 'my own cool signature')
Users can have custom .gh.json hooks.
But it's really only useful to have a ~/.gh.json when you've a custom setting. But we sometimes change the hooks.
How should we deal with it? Any ideas?
I think, for example, issues.new.after should only exist in my ~/.gh.json file (or repo gh.json) if, and only if, it modifies the default gh.json config.
Maybe JSON5 would help by allowing us to add a little comment (or something more complex) about the available hooks, but I think it's overkill.
Written by @henvic on #319
Right now it overwrites everything for a given root-level key.
Do you guys think it's worth the hassle to improve the merging?
Hooked with a .gh.json:
henvic at henvic-mp in ~/projects/foo (fix-user-hooks●●)
$ gh al
gh [info] Listing aliases
gh henrique ➜ henvic
and
Using default .gh.json:
henvic at henvic-mp in ~/projects/social-network (master●)
$ gh al
gh [info] Listing aliases
gh dudu ➜ eduardolundgren
gh maira ➜ mairatma
gh zeno ➜ zenorocha
gh z ➜ zenorocha
gh m ➜ mairatma
gh e ➜ eduardolundgren
Written by @henvic on #320
A simple idea would be to leverage the update-notifier package and have a custom link in there to release notes (or a FAQ) when we bump the npm version.
https://github.com/yeoman/update-notifier#options-and-custom-message
The release notes/FAQ can then explain something to the effect of:
"When changing the version of this package, we may have updated the default.gh.json file. If you have customized your .gh-username.json make sure to cross check it so that you don't overwrite the new changes that have been added"
Or something more descriptive and clear ha!
Another idea would be to check their ~/.gh.json file and cross check it with our default.gh.json file to see if theirs is missing any keys. If keys are missing, we could write them to ~/.gh.json. For superfluous keys we could either delete them or just leave them be.