Skip to content

[Proposal] Refactor ng-dev's pr directory to disentangle the utilities and common pieces #203

Closed
@josephperrott

Description

@josephperrott

Currently we have a structure like this.

ng-dev/pr                   
├── checkout                │ Checks out a PR locally to modify
├── check-target-branches   │ Prints the branches a pr would merge into
├── common                  │ 
│   └── checkout-pr.ts      │ Actual logic for checking out a PR used by checkout and rebase
├── discover-new-conflicts  │ Determines what other pending PRs can merge cleanly after a PR merges
├── merge                   │ Merges PRs (also houses the config.ts)
└── rebase                  │ Attempts to rebase a PR and push the rebased commits back to upstream

We have had a few people ask for something akin to ng-dev pr check <pr-number>, which would return the pr title, number, if it needs approvals, what branches it would land in etc. I think we should transform the check-target-branches into this command.

I would propose that we then separate out a few pieces that can be reused both literally in other files/commands and conceptually.

ng-dev/pr                   
├── checkout                │ Stays the same
├── info                    │ Leverage the validation logic and PullRequest object to get all PR info
├── common                  │ 
│   ├── checkout-pr         │ Stays the same
│   ├── get-pr              │ Common util to get PR from github as a consistent PullRequest object
│   ├── targeting           │ Target labels and utils to get a target branch for a PR, etc
│   └── validation          │ Validate that a PR meets all of the expected criteria for the repo
├── discover-new-conflicts  │ Stays the same
├── merge                   │ Merges PR, using the new common utils
└── rebase                  │ Stays the same
  • config.ts should move up one level into ng-dev/pr
  • MergeConfig should be renamed to something like PullRequestConfig

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions