Support offline / "dry run" options
jacobq opened this issue · comments
README says that it interacts with GitHub API, but it would be nice if there were more details about this. It makes sense that one would need to authenticate to publish, but I don't understand why I would need to authenticate in order to generate a changelog for a local repository. Taking a quick look it looks like the GitHub API is used in src/changelog.ts to lookup committers.
Admittedly, I'm an outsider (not currently using lerna in any of my own projects yet), but I think it is troubling that #3 (feature request for support for GitLab) has been open for 6 years (even if it might simply be because no contributors are interested in working on that). Even as a GitHub user though, I would like to be able to try out this package locally without giving it access to any online services. How much effort would be required to add support for an option like --offline or --dry-run that skip (or gracefully degrade) steps that currently require connection/authentication with GitHub?
It seems to me like other issues could also benefit from temporarily side-stepping, if not fulling decoupling, GitHub-specific features of lerna, e.g. #413, #130, #314 , #132
the changelog generator looks up merge commits from the local repository clone and then queries GitHub for additional metadata like the title of the PR and the labels on the PR to allow for categorization. GitLab has similar features so it is absolutely possible to support that too if someone would extract a generic interface. An offline mode is harder though because all of that metadata can't be queried then.
An offline mode is harder though because all of that metadata can't be queried then.
Is it still hard to do if content related to that information is skipped? What I was envisioning was something like how a front-end web app would handle a missing browser feature: not delivering the same rich experience but at least delivering something.
I realize I'm somewhat conflating two issues (offline/unauthenticated mode & support for other APIs), but I think they could be addressed together. Instead of this.github, a generic provider could be selected by the constructor based on some new value in the configuration, e.g. GitHubAPI by default, SomeOtherAPI (like GitLab, if someone wants to write that), or FakeOfflineStubAPI (better name suggestions welcome). Of course, there are some details to nail down, such as how to shore-up differences in API capabilities (e.g. could define a method like getCapabilities, set flags like canGetUserData, or could simply return null from unsupported methods), but since the interfaces is pretty small (src/github-api.ts < 100 lines) that doesn't look daunting.
I will probably close this issue for now because I managed to get the info I needed using some other related tools so am not planning to work on this in the near future, but in case I come back to it later (or if others want to pick it up), do you you have any recommendations for a potential PR submitter? (I noticed that #133 was closed without merge...looked like it was going to be refactored as multiple separate PRs, but I couldn't find them)