Using shepherd to file issues?

[TheSavior]

Context

Hi! I'm on the React Native team at Facebook. We are working on a big reimplementation of the core framework which will result in a few different breaking changes in the API. Unfortunately, not all of these changes can be migrated with codemods. If they could, then shepherd would be an absolutely perfect tool for us to use to help migrate the community.

Instead, for some of these breaking changes, we are planning on writing guides and instructions for how to make these changes. Even those these migrations can't be automated, we'd like to help the community migrate as easily as possible.

We think Shepherd has a lot of the pieces to help us with this!

What we want to accomplish

What we would love to do is file issues on the repos that match the search criteria, linking to the lines of code that needs to change. To accomplish this we will still need to do the GitHub search, and check out the repos to find the specific callsites that will need to change (likely using an AST traversal).

A lot of the basics of what we want to do seem the same as what shepherd does today. The main difference is that instead of running a migration and opening a PR, we need to run a script to generate the issue text (the script would calculate the links to those lines of code) and post the issue.

I'm curious if you have any thoughts for us on if you think shepherd would be a reasonable tool for this, or if you'd recommend just building something separate?

[TheSavior]

From looking through the code, it seems like a reasonable approach would be to implement commands for issues, similar to the ones for PRs:

shepherd/src/cli.ts

Lines 19 to 21 in 538f65f

	import pr from './commands/pr';
	import prPreview from './commands/pr-preview';
	import prStatus from './commands/pr-status';

And then we'd run only these commands:

shepherd checkout ~/shepherd-migration
shepherd issue ~/shepherd-migration

Does that sound right to you?

[parshap]

Hey @TheSavior. This is awesome! Using Shepherd to lessen the burden of api changes is definitely type of use case we want to support.

Your idea with shepherd issue makes sense. I think the shepherd.yml migration file should also indicate that an issue should be opened instead of a pr (perhaps by using issue_message instead of pr_message). I would happily accept a PR for this.

PS: I've run into a similar use case before where I've wanted to add line comments on the PR that Shepherd opens.

[TheSavior]

Great! Having the issue command read something like issue_message sounds reasonable to me

[aorinevo]

Hi @TheSavior, apologies on the long hiatus. I'm just getting back into the swing of things and wanted to revisit this. I'm on the fence with respect to this feature. On the one hand, Shepherd is primarily focused on programmatic code changes and so this would be outside its scope. On the other hand, the proposed feature is targeting reducing developer toil at scale by way of programmatically creating issues.

Also, for full transparency, I've had a similar use case and opt'd to add the feature to a custom cli tooling my team uses.

While on the fence, I'm open to the idea and would like to see how this translates into code. I think your proposed top level apis make sense. If you're still keen on this feature being incorporated into Shepehrd, would you be open to taking a go at this?

[TheSavior]

Nice to hear from you! Some thoughts since I last posted.

I've thought about this issue a couple times a year since posting it. I still think this would be valuable for a lot of things we do across the React and React Native ecosystems where communicating with lots of libraries is important.

Since investigating shepherd, I've found that GitHub search wouldn't help us find the right repos, there are too many forks (not labeled as forks) to navigate through. Instead, we've been using https://reactnative.directory/ listing of repos. Now that we have the repos, we still find a need for this kind of tool, submitting PRs and issues against all of the repos.

That said, we haven't actually done it since I first posted this, although we've been talking about it more recently. With that in mind, I don't expect myself or someone from my group will prioritize building this ourselves until we actually need to use it for this.

[kavitha186]

@aorinevo I'm working on this issue

[aorinevo]

Thank you for taking this on, @kavitha186! I've assigned the issue, accordingly.

[aorinevo]

Hi @TheSavior, @kavitha186 is close to wrapping up development on the issues feature. When you get a chance, do you mind reviewing and providing feedback on #693. I want to ensure that the feature provides the functionality you and your team are after.