pr-report-core 0.2.0 → 0.3.0

package/src/checks.mts

@@ -6,36 +6,36 @@ import type { ChecksSummary, ContextState } from './types.mjs';
 /**
  * What every context reported, from a head commit's check runs.
  *
- * A name appears more than once whenever two check suites reported it, and on
- * a queued pull request that is the normal case rather than the odd one: the
- * run the `opened` event starts is cancelled by the `labeled` event's, and
- * both stay on the commit — the cancelled one leaving its `*-result`
- * aggregate concluded `failure`, because an `if: always()` job that asserts
- * on cancelled `needs` fails.
+ * A name appears more than once whenever two check suites reported it, and on a
+ * queued pull request that is the normal case rather than the odd one: the run
+ * the `opened` event starts is cancelled by the `labeled` event's, and both
+ * stay on the commit — the cancelled one leaving its `*-result` aggregate
+ * concluded `failure`, because an `if: always()` job that asserts on cancelled
+ * `needs` fails.
  *
- * **The newest check suite wins, and that is not the same as the newest
- * run.** GitHub resolves a required context to the run in the suite with the
- * greatest id, so where the cancelled suite happens to have been created
- * after the one that superseded it, the stale red is what holds the merge —
- * however much later the green one finished. Every suite of one push is
- * created in the same second, so which of them got the higher id is not
- * something the repository decides.
+ * **The newest check suite wins, and that is not the same as the newest run.**
+ * GitHub resolves a required context to the run in the suite with the greatest
+ * id, so where the cancelled suite happens to have been created after the one
+ * that superseded it, the stale red is what holds the merge — however much
+ * later the green one finished. Every suite of one push is created in the same
+ * second, so which of them got the higher id is not something the repository
+ * decides.
  *
  * This is why the rule is not "the newest `started_at`", which reads more
  * natural and would call such a pull request green while GitHub blocks it.
- * A report that says a blocked pull request will merge is worse than one
- * that says a green one will not: `CLAUDE.md`'s "Commits and pull requests"
- * says to ignore the red the cancelled run leaves, and this is the case where
+ * A report that says a blocked pull request will merge is worse than one that
+ * says a green one will not: `CLAUDE.md`'s "Commits and pull requests" says to
+ * ignore the red the cancelled run leaves, and this is the case where
  * GitHub does not.
  *
  * **A run whose workflow has a newer round still going is pending.** An
- * aggregate has no run in a round until the jobs it waits on are done, so
- * until then the only run of its name is the previous round's — on a pull
- * request whose label events started two rounds, the red the second left on
- * the first (#2191). That run is what GitHub shows, but not what it will
- * answer with: the newer round is in the suite with the greater id, and its
- * aggregate will be the newest run of the name. Where the newer round has
- * finished without one, the older run stands, as it does on GitHub.
+ * aggregate has no run in a round until the jobs it waits on are done, so until
+ * then the only run of its name is the previous round's — on a pull request
+ * whose label events started two rounds, the red the second left on the first
+ * (#2191). That run is what GitHub shows, but not what it will answer with: the
+ * newer round is in the suite with the greater id, and its aggregate will be
+ * the newest run of the name. Where the newer round has finished without one,
+ * the older run stands, as it does on GitHub.
  */
 export const statesFromCheckRuns = (
   runs: readonly CheckRunReport[],
@@ -101,9 +101,9 @@ export type CheckRunReport = Readonly<{
   /**
    * The workflow run its suite is, where it is one: the workflow, so that a
    * newer round of it can be told from an unrelated suite, and whether the
-   * round has finished, which its runs alone do not say — an aggregate's run
-   * is created only once every job before it has completed. `undefined` for
-   * a run no workflow made, or where the workflow runs could not be read.
+   * round has finished, which its runs alone do not say — an aggregate's run is
+   * created only once every job before it has completed. `undefined` for a run
+   * no workflow made, or where the workflow runs could not be read.
    */
   round: Readonly<{ workflowId: number; completed: boolean }> | undefined;
 }>;
@@ -114,12 +114,12 @@ export type CheckRunReport = Readonly<{
  * A run that has not completed is pending whatever it concluded last — the
  * conclusion of a re-run is the previous verdict until the new one finishes.
  * A `skipped` conclusion is reported as `skipped` and counted as met by
- * {@link summarizeChecks}, because GitHub counts it as met: the gated jobs
- * skip on `skip-ci` and on a diff the workflow does not read, and reading
- * that as a failure would call every gated pull request red.
+ * {@link summarizeChecks}, because GitHub counts it as met: the gated jobs skip
+ * on `skip-ci` and on a diff the workflow does not read, and reading that as a
+ * failure would call every gated pull request red.
  * Everything else that finished — `cancelled`, `stale`, `timed_out`,
- * `action_required` — is something a reader has to act on, so it is a
- * failure here even where GitHub is vaguer about it.
+ * `action_required` — is something a reader has to act on, so it is a failure
+ * here even where GitHub is vaguer about it.
  */
 export const classifyCheckRun = (
   status: string,
@@ -141,12 +141,12 @@ const PASSING_CONCLUSIONS: ReadonlySet<string> = new Set<string>([
 /**
  * Whether any run on the head commit has not finished, or any round has not.
  *
- * Every run, not only the required ones: the aggregates are `if: always()`
- * and have no run in the newest round until the jobs they wait on are done,
- * so "every required context has reported" is true of a commit halfway
- * through a round — with the reports coming from the round before. And the
- * round, not only its runs: between the last job finishing and the aggregate
- * being created, every run there is has completed.
+ * Every run, not only the required ones: the aggregates are `if: always()` and
+ * have no run in the newest round until the jobs they wait on are done, so
+ * "every required context has reported" is true of a commit halfway through a
+ * round — with the reports coming from the round before. And the round, not
+ * only its runs: between the last job finishing and the aggregate being
+ * created, every run there is has completed.
  */
 export const anyRunInProgress = (runs: readonly CheckRunReport[]): boolean =>
   runs.some(
@@ -154,10 +154,10 @@ export const anyRunInProgress = (runs: readonly CheckRunReport[]): boolean =>
   );
 
 /**
- * What every context has reported on one commit, from both places GitHub
- * keeps them. The aggregate jobs are check runs; `no-skip-ci-label` is a
- * commit status, so reading only the first would report the context that
- * holds every labelled pull request as missing.
+ * What every context has reported on one commit, from both places GitHub keeps
+ * them. The aggregate jobs are check runs; `no-skip-ci-label` is a commit
+ * status, so reading only the first would report the context that holds every
+ * labelled pull request as missing.
  *
  * `state` is a commit status's as the REST API spells it, in lower case.
  */
@@ -165,9 +165,9 @@ export const reportedContexts = (
   runs: readonly CheckRunReport[],
   statuses: readonly Readonly<{ context: string; state: string }>[],
 ): ReadonlyMap<string, ContextState> => {
-  // A commit status and a check run of the same name are two requirements,
-  // not one reported twice: GitHub asks both to pass. So the stricter of
-  // the two is kept rather than whichever was read second.
+  // A commit status and a check run of the same name are two requirements, not
+  // one reported twice: GitHub asks both to pass. So the stricter of the two is
+  // kept rather than whichever was read second.
   const mut_states = new Map<string, ContextState>(statesFromCheckRuns(runs));
 
   for (const { context, state } of statuses) {
@@ -189,12 +189,11 @@ export const reportedContexts = (
 /**
  * What a context reported that is both a check run and a commit status.
  *
- * Not "the status wins", which is what this used to assume. GitHub's own
- * answer is that neither does: "If a check and a commit status have the same
- * name, both must pass when that name is required." So the stricter of the
- * two is the verdict, and a green status cannot cover a red check run of the
- * same name. A skip beside a pass is a skip: both are met, but only one of
- * them ran.
+ * Not "the status wins", which is what this used to assume. GitHub's own answer
+ * is that neither does: "If a check and a commit status have the same name,
+ * both must pass when that name is required." So the stricter of the two is the
+ * verdict, and a green status cannot cover a red check run of the same name. A
+ * skip beside a pass is a skip: both are met, but only one of them ran.
  */
 export const combineContextStates = (
   a: ContextState,
@@ -210,8 +209,8 @@ export const combineContextStates = (
 
 /**
  * What one commit status has reported. `no-skip-ci-label` is one of these
- * rather than a check run, so a report that read only check runs would call
- * the context that holds every labelled pull request "missing".
+ * rather than a check run, so a report that read only check runs would call the
+ * context that holds every labelled pull request "missing".
  */
 export const classifyCommitStatus = (state: string): ContextState => {
   switch (state) {
@@ -231,24 +230,24 @@ export const classifyCommitStatus = (state: string): ContextState => {
  * requires and no others: a failing job nothing requires does not block a
  * merge, and listing it would bury the one that does.
  *
- * `paused` outranks the rest. While `skip-ci` is on, the checks a reader
- * sees are whatever survived from before the label went on — typically the
- * red left by the `opened` run that the `labeled` run cancelled. Calling
- * that "failing" would make every queued pull request look broken; the
- * failures are still listed, because they are what a reader asks about.
+ * `paused` outranks the rest. While `skip-ci` is on, the checks a reader sees
+ * are whatever survived from before the label went on — typically the red left
+ * by the `opened` run that the `labeled` run cancelled. Calling that "failing"
+ * would make every queued pull request look broken; the failures are still
+ * listed, because they are what a reader asks about.
  *
  * `running` is the third thing that makes a verdict provisional, beside a
- * required context that is pending and one that has not reported. Without it
- * a commit mid-round reads as settled out of the round before — which is how
- * a failing pull request (#2031) came to show a tick.
+ * required context that is pending and one that has not reported. Without it a
+ * commit mid-round reads as settled out of the round before — which is how a
+ * failing pull request (#2031) came to show a tick.
  *
  * **Off the covered base, a context that never reported is not awaited.**
  * The contexts are the ones the ruleset asks of `main`, and a workflow that
- * runs only on pull requests into `main` never reports on a stacked one —
- * which kept #2103, every check of it green, "running" until it was moved
- * onto `main`. Such a context is {@link ChecksSummary.notRun} instead, but
- * only once some required context has reported: before the first check
- * suite, nothing having come is not a pass over zero contexts.
+ * runs only on pull requests into `main` never reports on a stacked one — which
+ * kept #2103, every check of it green, "running" until it was moved onto
+ * `main`. Such a context is {@link ChecksSummary.notRun} instead, but only once
+ * some required context has reported: before the first check suite, nothing
+ * having come is not a pass over zero contexts.
  */
 export const summarizeChecks = ({
   required,

package/src/checks.test.mts

@@ -17,11 +17,11 @@ describe(classifyCheckRun, () => {
     assert.strictEqual(classifyCheckRun('in_progress', 'failure'), 'pending');
   });
 
-  // The gated jobs skip on `skip-ci` and on a diff the workflow does not
-  // read; GitHub counts that as met, so reading it as a failure would call
-  // every gated pull request red. `summarizeChecks` still counts it as met —
-  // but it is reported as what it was, because folding it into `passed` is
-  // what let a failing pull request show a tick.
+  // The gated jobs skip on `skip-ci` and on a diff the workflow does not read;
+  // GitHub counts that as met, so reading it as a failure would call every
+  // gated pull request red. `summarizeChecks` still counts it as met — but it
+  // is reported as what it was, because folding it into `passed` is what let a
+  // failing pull request show a tick.
   test('a skipped job is reported as skipped, not as passed', () => {
     assert.strictEqual(classifyCheckRun('completed', 'skipped'), 'skipped');
 
@@ -114,10 +114,9 @@ describe(summarizeChecks, () => {
 
   test('`skip-ci` is a pause, and the detail is still reported', () => {
     // While the label is on, the gated jobs boot no runner and
-    // `no-skip-ci-label` sits `pending` by design. Calling that "failing"
-    // would make every queued pull request look broken; the red left by the
-    // cancelled `opened` run is still listed, because it is what a reader
-    // asks about.
+    // `no-skip-ci-label` sits `pending` by design. Calling that "failing" would
+    // make every queued pull request look broken; the red left by the cancelled
+    // `opened` run is still listed, because it is what a reader asks about.
     const summary = summarizeChecks({
       required,
       reported: new Map<string, ContextState>([
@@ -207,9 +206,9 @@ describe(summarizeChecks, () => {
   });
 
   // #2103, stacked on `chore/pnpm-update`: `lint-pull-request.yml` runs on
-  // pull requests into `main` only, so its three contexts never came, and
-  // the page kept calling a pull request whose checks had all passed
-  // "checks running".
+  // pull requests into `main` only, so its three contexts never came, and the
+  // page kept calling a pull request whose checks had all passed "checks
+  // running".
   describe('on a base the ruleset does not cover', () => {
     const withLint = Arr.toPushed(required, 'Validate PR title');
 
@@ -235,8 +234,8 @@ describe(summarizeChecks, () => {
     });
 
     test('while nothing required has reported, everything is still coming', () => {
-      // Between a push and the first check suite, a head commit has nothing
-      // on it at all; that is not a pass over zero contexts.
+      // Between a push and the first check suite, a head commit has nothing on
+      // it at all; that is not a pass over zero contexts.
       const summary = summarizeChecks({
         required: withLint,
         reported: new Map<string, ContextState>(),
@@ -331,8 +330,8 @@ describe(statesFromCheckRuns, () => {
     // `test-node-versions-result`, the one context of the five that blocked
     // #2021: the cancelled suite happens to have the greater id, so GitHub
     // reports the failure however much later the green one finished. Reading
-    // the newest `started_at` instead would call this pull request green
-    // while GitHub blocks it.
+    // the newest `started_at` instead would call this pull request green while
+    // GitHub blocks it.
     const states = statesFromCheckRuns([
       run(
         'test-node-versions-result / result',
@@ -496,11 +495,11 @@ describe(anyRunInProgress, () => {
  * The state #2031 was in when the page showed it a tick.
  *
  * `skip-ci` came off, which started a new round. The old round's
- * `code-check-result` had concluded `skipped` and was the only run of that
- * name on the commit — the new round's aggregate does not exist until the
- * jobs it waits on are done. Folding `skipped` into `passed` then made the
- * pull request look settled and green, two minutes before
- * `code-check-result` concluded `failure`.
+ * `code-check-result` had concluded `skipped` and was the only run of that name
+ * on the commit — the new round's aggregate does not exist until the jobs it
+ * waits on are done. Folding `skipped` into `passed` then made the pull request
+ * look settled and green, two minutes before `code-check-result` concluded
+ * `failure`.
  */
 describe('a required context in a superseded round', () => {
   const required = [
@@ -607,9 +606,9 @@ describe('a required context in a superseded round', () => {
  * `skip-ci` came off, which started a round, and `merge-queued` went on a
  * minute later, which started another and cancelled the first — whose
  * `*-result` aggregates, `if: always()` over cancelled `needs`, concluded
- * `failure`. The newer round was still at its matrix, so its aggregates did
- * not exist yet, and the red of the cancelled one was the only run of each
- * name on the commit.
+ * `failure`. The newer round was still at its matrix, so its aggregates did not
+ * exist yet, and the red of the cancelled one was the only run of each name on
+ * the commit.
  */
 describe('a required context whose workflow has a newer round running', () => {
   const codeCheck = 359_266_435;
@@ -659,8 +658,8 @@ describe('a required context whose workflow has a newer round running', () => {
       conclusion: undefined,
       round: { workflowId: codeCheck, completed: false },
     },
-    // Style Check has finished every job it has created, but the round is
-    // not over: its aggregate is created only after that.
+    // Style Check has finished every job it has created, but the round is not
+    // over: its aggregate is created only after that.
     {
       id: 114_375_644_790,
       checkSuiteId: 103_247_840_622,
@@ -719,8 +718,8 @@ describe('a required context whose workflow has a newer round running', () => {
   });
 
   // The rule is not "an older round never counts": where the newer round
-  // finished without a run of that name, GitHub answers with the older run,
-  // and so does this.
+  // finished without a run of that name, GitHub answers with the older run, and
+  // so does this.
   test('a finished round that never ran the job does not hide the older run', () => {
     const states = statesFromCheckRuns([
       runs[0],
@@ -737,9 +736,9 @@ describe('a required context whose workflow has a newer round running', () => {
     assert.strictEqual(states.get('code-check-result / result'), 'failed');
   });
 
-  // Nor "the round still running wins": GitHub resolves a context to the
-  // suite with the greatest id, and where the cancelled one has it, its red
-  // holds the merge however the other round goes.
+  // Nor "the round still running wins": GitHub resolves a context to the suite
+  // with the greatest id, and where the cancelled one has it, its red holds the
+  // merge however the other round goes.
   test('a cancelled round with the greater id still holds the merge', () => {
     const states = statesFromCheckRuns([
       {

package/src/claim.mts

@@ -3,26 +3,26 @@
  * writer of the queue can read it.
  *
  * `unblock-prs` leaves a set-aside pull request alone until its head moves —
- * or, for every reason but `checks-failed` and `awaiting-bypass`, until the
- * base does, when it tries the rebase again. A session fixing that pull
- * request is then racing the script, and a second session, or the one that
- * opened the pull request and is woken by the set-aside comment, may be
- * fixing the same failure. The leases on every push keep any of them from
- * overwriting another's work, but not from doing it twice. So whoever starts
- * on one says so first in a comment whose first line is a hidden record this
- * module writes and reads, and everyone else — the script included — leaves
- * that pull request to it.
+ * or, for every reason but `checks-failed`, `awaiting-bypass` and
+ * `head-out-of-sync`, until the base does, when it tries the rebase again. A
+ * session fixing that pull request is then racing the script, and a second
+ * session, or the one that opened the pull request and is woken by the
+ * set-aside comment, may be fixing the same failure. The leases on every push
+ * keep any of them from overwriting another's work, but not from doing it
+ * twice. So whoever starts on one says so first in a comment whose first line
+ * is a hidden record this module writes and reads, and everyone else — the
+ * script included — leaves that pull request to it.
  *
  * **It lasts while the head is the one it claimed**, and for at most
  * {@link CLAIM_LIFETIME_MINUTES}. The push that carries the fix moves the head
- * and so ends the claim with nothing left to clean up; that push is what
- * hands the pull request back to the script, as it always was. The lifetime is
- * for a claimant that stopped without pushing. A claimant that needs longer
- * writes the claim again.
+ * and so ends the claim with nothing left to clean up; that push is what hands
+ * the pull request back to the script, as it always was. The lifetime is for a
+ * claimant that stopped without pushing. A claimant that needs longer writes
+ * the claim again.
  *
  * **One comment per pull request, edited in place**, like the set-aside one;
- * a claim that has ended is simply written over. Of several, the oldest is
- * the one, so two claimants writing at once both read back the same answer.
+ * a claim that has ended is simply written over. Of several, the oldest is the
+ * one, so two claimants writing at once both read back the same answer.
  *
  * **Only the comments the reader's own account wrote count**, as for the
  * set-aside comment (`set-aside.mts`): the repository is public. `by` is what
@@ -114,7 +114,7 @@ export const claimApplies = (
  * Further than that is a clock that would otherwise stretch the lifetime by
  * however far ahead it ran.
  */
-const CLOCK_SKEW_MINUTES = 5;
+export const CLOCK_SKEW_MINUTES = 5;
 
 const MS_PER_MINUTE = 60_000;
 

package/src/closing-issues.mts

@@ -19,15 +19,14 @@ export type ClosingIssueNode = Readonly<{
 /**
  * The closing issues that belong to `repo`, in GitHub's order.
  *
- * **Only this repository's.** A pull request can close an issue anywhere,
- * and a report lists each as `#N` — which for another repository's issue
- * names a different issue of this one, and for a private repository's may
- * put a title the report's reader cannot see into a report someone else
- * reads. The body parser `pr-report` falls back on without a token draws the
- * same line.
+ * **Only this repository's.** A pull request can close an issue anywhere, and a
+ * report lists each as `#N` — which for another repository's issue names a
+ * different issue of this one, and for a private repository's may put a title
+ * the report's reader cannot see into a report someone else reads. The body
+ * parser `pr-report` falls back on without a token draws the same line.
  *
- * `null` entries are skipped rather than rejected: one issue the token may
- * not see is no reason to lose the rest.
+ * `null` entries are skipped rather than rejected: one issue the token may not
+ * see is no reason to lose the rest.
  */
 export const closingIssuesIn = (
   repo: RepoRef,
@@ -55,21 +54,21 @@ export const closingIssuesIn = (
 };
 
 /**
- * The issues of `repo` a pull request body closes by keyword, as GitHub
- * itself read the body: first appearance order, each once.
+ * The issues of `repo` a pull request body closes by keyword, as GitHub itself
+ * read the body: first appearance order, each once.
  *
  * **Read from GitHub's rendering, not from the text.** GitHub wraps each
- * closing keyword it recognized in `<span class="issue-keyword">` and puts
- * the reference right after it, and it does so whatever the base branch.
- * `closingIssuesReferences` does not: it links a keyword only on a pull
- * request into the default branch, so a stacked one lists nothing until the
- * layers below it merge. Which spellings count, whether a reference inside
- * code or after a comma is closed, is GitHub's to decide, and this takes its
- * decision rather than copying the grammar. A body cannot forge the mark:
+ * closing keyword it recognized in `<span class="issue-keyword">` and puts the
+ * reference right after it, and it does so whatever the base branch.
+ * `closingIssuesReferences` does not: it links a keyword only on a pull request
+ * into the default branch, so a stacked one lists nothing until the layers
+ * below it merge. Which spellings count, whether a reference inside code or
+ * after a comma is closed, is GitHub's to decide, and this takes its decision
+ * rather than copying the grammar. A body cannot forge the mark:
  * GitHub strips `class` from HTML written in one.
  *
- * A reference to another repository's issue, or to a pull request, is left
- * out, for the reasons {@link closingIssuesIn} gives.
+ * A reference to another repository's issue, or to a pull request, is left out,
+ * for the reasons {@link closingIssuesIn} gives.
  */
 export const closingKeywordIssuesIn = (
   repo: RepoRef,

package/src/closing-issues.test.mts

@@ -145,8 +145,8 @@ describe(closingKeywordIssuesIn, () => {
 });
 
 /**
- * A reference as GitHub renders it in a pull request's `bodyHTML`, with
- * the attributes in the order GitHub writes them.
+ * A reference as GitHub renders it in a pull request's `bodyHTML`, with the
+ * attributes in the order GitHub writes them.
  */
 const link = (
   nameWithOwner: string,

package/src/code-owners.mts

@@ -3,18 +3,18 @@
  *
  * Read because GitHub will not say. `main`'s ruleset has
  * `require_code_owner_review` on, so a pull request touching an owned path
- * waits for an owner to approve it — and nothing on a pull request reports
- * that wait: `reviewDecision` answers `null` for every pull request here,
- * owned paths or not, because it describes branch protection rather than a
- * ruleset. So it is worked out the way GitHub does, from the file — by the
- * Pull Requests Manager page, to show the wait, and by `unblock-prs`, to
- * leave a pull request that waits in the queue rather than run its checks.
+ * waits for an owner to approve it — and nothing on a pull request reports that
+ * wait: `reviewDecision` answers `null` for every pull request here, owned
+ * paths or not, because it describes branch protection rather than a ruleset.
+ * So it is worked out the way GitHub does, from the file — by the
+ * Pull Requests Manager page, to show the wait, and by `unblock-prs`, to leave
+ * a pull request that waits in the queue rather than run its checks.
  *
- * The patterns are the subset of `.gitignore` syntax GitHub documents for
- * this file: a leading `/` or a `/` in the middle anchors a pattern to the
- * root, a trailing `/` makes it a directory, `*` and `?` stay inside one path
- * segment and `**` crosses them. Negation and character ranges are not
- * supported by GitHub here either.
+ * The patterns are the subset of `.gitignore` syntax GitHub documents for this
+ * file: a leading `/` or a `/` in the middle anchors a pattern to the root, a
+ * trailing `/` makes it a directory, `*` and `?` stay inside one path segment
+ * and `**` crosses them. Negation and character ranges are not supported by
+ * GitHub here either.
  */
 
 import { Arr } from 'ts-data-forge';
@@ -22,8 +22,8 @@ import { Arr } from 'ts-data-forge';
 export type CodeOwnersRule = Readonly<{
   pattern: string;
   /**
-   * Without the leading `@`. Empty for a pattern that clears the owners of
-   * what an earlier line matched.
+   * Without the leading `@`. Empty for a pattern that clears the owners of what
+   * an earlier line matched.
    */
   owners: readonly string[];
 }>;
@@ -45,9 +45,9 @@ export const parseCodeOwners = (text: string): readonly CodeOwnersRule[] =>
   });
 
 /**
- * The owners of one path: those of the **last** pattern that matches it,
- * which is how GitHub reads the file — a later line overrides an earlier one
- * rather than adding to it.
+ * The owners of one path: those of the **last** pattern that matches it, which
+ * is how GitHub reads the file — a later line overrides an earlier one rather
+ * than adding to it.
  */
 export const ownersOf = (
   path: string,
@@ -57,19 +57,18 @@ export const ownersOf = (
 
 /**
  * What GitHub would say, worked out the way GitHub does: every changed path
- * that has owners needs an approval from one of them. An approval is the
- * latest review of an owner that says so; one dismissed by a later push —
- * the ruleset dismisses stale approvals — no longer counts, and GitHub has
- * already stopped calling it an approval by the time this reads it.
+ * that has owners needs an approval from one of them. An approval is the latest
+ * review of an owner that says so; one dismissed by a later push — the ruleset
+ * dismisses stale approvals — no longer counts, and GitHub has already stopped
+ * calling it an approval by the time this reads it.
  *
- * Owners are compared by login, case-insensitively, as GitHub compares
- * them. A team owner (`@org/team`) cannot be: telling who is on the team
- * takes `read:org`, which neither reader asks for. So a path a team owns
- * waits while nobody at all has approved, is approved by a person owning it
- * beside the team, and otherwise — someone approved, and might be on the
- * team — cannot be told, which makes the whole `unknown` unless another
- * path is plainly still waiting. `CODEOWNERS` in this repository names no
- * team.
+ * Owners are compared by login, case-insensitively, as GitHub compares them. A
+ * team owner (`@org/team`) cannot be: telling who is on the team takes
+ * `read:org`, which neither reader asks for. So a path a team owns waits while
+ * nobody at all has approved, is approved by a person owning it beside the
+ * team, and otherwise — someone approved, and might be on the team — cannot be
+ * told, which makes the whole `unknown` unless another path is plainly still
+ * waiting. `CODEOWNERS` in this repository names no team.
  */
 export const codeOwnerReview = ({
   required,
@@ -150,8 +149,8 @@ const stripComment = (line: string): string => {
   return at === -1 ? line : line.slice(0, at);
 };
 
-// Not `RegExp.escape`: it arrived in Node 24, and `ws:check:test` also runs
-// on the `engines.node` floor (`test-node-versions (minimum)`), which is 22.
+// Not `RegExp.escape`: it arrived in Node 24, and `ws:check:test` also runs on
+// the `engines.node` floor (`test-node-versions (minimum)`), which is 22.
 // Under the `u` flag only the syntax characters and `/` may be escaped, and
 // everything else is a literal as it stands.
 const escapeChar = (char: string): string =>
@@ -187,11 +186,10 @@ const toRegExp = (pattern: string): RegExp => {
 
   const body = globToRegExpSource(trimmed);
 
-  // A directory owns what is under it and never matches as a file. A name
-  // with no trailing slash may be either, so it matches itself and what is
-  // under it — unless its last segment is a wildcard, which GitHub reads as
-  // files at that level only: `docs/*` owns `docs/a.md` and not
-  // `docs/build/a.md`.
+  // A directory owns what is under it and never matches as a file. A name with
+  // no trailing slash may be either, so it matches itself and what is under it
+  // — unless its last segment is a wildcard, which GitHub reads as files at
+  // that level only: `docs/*` owns `docs/a.md` and not `docs/build/a.md`.
   const tail = directory
     ? '/.+'
     : (trimmed.split('/').at(-1) ?? '').includes('*')
@@ -206,12 +204,12 @@ const toRegExp = (pattern: string): RegExp => {
  * Where a pull request stands with the code owners.
  *
  * `required` lists what is still waiting — the owned paths no owner has
- * approved yet, and who could approve them. `authorOwns` is the case that
- * waits for ever: GitHub does not let an author approve their own pull
- * request, so when the author is the only owner nothing but a ruleset bypass
- * will merge it. `unknown` is a pull request whose changed files were more
- * than could be read, where the unread ones might be owned — or, with
- * `teams`, one approved by someone these teams might have as a member.
+ * approved yet, and who could approve them. `authorOwns` is the case that waits
+ * for ever: GitHub does not let an author approve their own pull request, so
+ * when the author is the only owner nothing but a ruleset bypass will merge it.
+ * `unknown` is a pull request whose changed files were more than could be read,
+ * where the unread ones might be owned — or, with `teams`, one approved by
+ * someone these teams might have as a member.
  */
 export type CodeOwnerReview = Readonly<
   | { state: 'approved' }

package/src/index.mts

@@ -1,7 +1,10 @@
+export * from './branch-rules.mjs';
 export * from './checks.mjs';
 export * from './claim.mjs';
 export * from './closing-issues.mjs';
 export * from './code-owners.mjs';
+export * from './issue-claim.mjs';
+export * from './issue-priority.mjs';
 export * from './labels.mjs';
 export * from './merge-after.mjs';
 export * from './queue-comments.mjs';