@gitkraken/core-gitlens 0.6.0 → 0.7.1

package/src/plus/git-github/api/github.utils.ts

@@ -1,36 +0,0 @@
-import type { PullRequestUrlIdentity } from '../../../git/utils/pullRequest.utils.js';
-
-export function isMaybeGitHubPullRequestUrl(url: string): boolean {
-	if (url == null) return false;
-	return getGitHubPullRequestIdentityFromMaybeUrl(url) != null;
-}
-
-export function getGitHubPullRequestIdentityFromMaybeUrl(
-	search: string,
-): (PullRequestUrlIdentity & { provider: undefined }) | undefined;
-export function getGitHubPullRequestIdentityFromMaybeUrl<T extends string>(
-	search: string,
-	id: T,
-): (PullRequestUrlIdentity & { provider: T }) | undefined;
-export function getGitHubPullRequestIdentityFromMaybeUrl<T extends string>(
-	search: string,
-	id?: T,
-): (PullRequestUrlIdentity & { provider: T | undefined }) | undefined {
-	let ownerAndRepo: string | undefined = undefined;
-	let prNumber: string | undefined = undefined;
-
-	let match = search.match(/([^/]+\/[^/]+)\/(?:pull)\/(\d+)/); // with org and rep name
-	if (match != null) {
-		ownerAndRepo = match[1];
-		prNumber = match[2];
-	}
-
-	if (prNumber == null) {
-		match = search.match(/(?:\/|^)(?:pull)\/(\d+)/); // without repo name
-		if (match != null) {
-			prNumber = match[1];
-		}
-	}
-
-	return prNumber != null ? { ownerAndRepo: ownerAndRepo, prNumber: prNumber, provider: id } : undefined;
-}

package/src/plus/git-github/api/issueSearchQuery.ts

@@ -1,273 +0,0 @@
-import type {
-	IssueSearchCriteria,
-	IssueSearchRelationship,
-	IssueSortField,
-	IssueSorting,
-} from '../../../git/models/issue.js';
-
-/**
- * Translation of the provider-neutral issue-search criteria into GitHub search qualifiers, and the sanitizing
- * that keeps user input from becoming one.
- *
- * A module of its own because it is pure string building with no client, no token and no network — the part of the
- * search that is worth reading, testing and reasoning about on its own, and the part where a mistake is a
- * SECURITY mistake rather than a failed request: an unsanitized value that escapes its qualifier re-scopes
- * someone's search. Keeping it out of the 4000-line API client is what makes that reviewable.
- */
-
-/**
- * Neutralizes everything in a user-supplied value that could break out of the qualifier it lands in: the double
- * quote that would close its own `"…"`, and the control characters that cannot appear in a GitHub search query
- * and exist here only as a smuggling vector.
- *
- * Not a general escape — GitHub search has no escape syntax — so the only safe transformation is removal. But a
- * control character is REPLACED WITH A SPACE rather than deleted, because deleting it FUSES the words it separated:
- * a pasted or multi-line `graph\nperformance` became the single token `graphperformance`, which matches nothing —
- * turning a search that had results into a silent zero (measured: 2 results vs 0). Quotes are still deleted
- * outright; they separate nothing, so a space there would only pad the value.
- *
- * Runs of whitespace are collapsed afterwards so the emitted qualifier stays canonical — a doubled space inside
- * `label:"a  b"` would not match the label `a b`.
- */
-export function sanitizeGitHubQualifierValue(value: string): string {
-	return (
-		value
-			.replace(/"/g, '')
-			// eslint-disable-next-line no-control-regex
-			.replace(/[\u0000-\u001f\u007f]/g, ' ')
-			.replace(/\s+/g, ' ')
-			.trim()
-	);
-}
-
-/**
- * Sanitizes free text, which is a different problem from a qualifier value: bare words are the POINT here, so it
- * can't just be quoted. What must not survive is anything that would read as a qualifier — GitHub parses any
- * whitespace-delimited `key:value` token as one, so a user typing `foo org:someone-else` would otherwise re-scope
- * the search to another org.
- *
- * Tokens containing `:` are dropped whole rather than having the colon removed: the remainder would silently
- * change what the user searched for, and a dropped token at least matches nothing extra. The structured criteria
- * are the qualifier channel.
- */
-export function sanitizeGitHubSearchText(text: string): string {
-	return sanitizeGitHubQualifierValue(text)
-		.split(/\s+/)
-		.filter(token => token.length > 0 && !token.includes(':'))
-		.join(' ');
-}
-
-/**
- * How each relationship is expressed: its GitHub search qualifier (`@me` binds to the token's own user), and the
- * GraphQL alias its search runs under.
- *
- * The aliases are LITERALS rather than derived from the relationship name, for two reasons: `any-assignee` is not
- * a valid GraphQL name, and an alias is also a persisted cursor key (see {@link GitHubApi.searchIssuesByAlias}),
- * so it must be stable across releases — spelling them out makes that immovability visible instead of an
- * emergent property of a transform. Being a `Record` over the union, the type fails the build if a relationship
- * is added without both, rather than silently emitting an unconstrained search.
- */
-export const gitHubIssueSearchRelationships: Record<IssueSearchRelationship, { qualifier: string; alias: string }> = {
-	authored: { qualifier: 'author:@me', alias: 'authored' },
-	assigned: { qualifier: 'assignee:@me', alias: 'assigned' },
-	mentioned: { qualifier: 'mentions:@me', alias: 'mentioned' },
-	'any-assignee': { qualifier: 'assignee:*', alias: 'anyAssignee' },
-	unassigned: { qualifier: 'no:assignee', alias: 'unassigned' },
-};
-
-/**
- * How each orderable key becomes a GitHub `sort:` qualifier.
- *
- * A literal table rather than a derived transform, for the same reason {@link gitHubIssueSearchRelationships} is
- * one: being a `Record` over the union means adding a sort field without deciding its qualifier FAILS THE BUILD,
- * instead of quietly emitting a search with no ordering constraint at all — which is the one failure mode the
- * ordering contract exists to prevent, and the one a caller cannot detect from the result.
- *
- * `updated:desc` maps to the bare `sort:updated`, not `sort:updated-desc`. The two are the same query to GitHub,
- * but the bare form is what this read has always emitted, so keeping it makes the default byte-identical to
- * today's query — and the exact-query tests and recorded fixtures stay valid. Do not "normalize" it.
- *
- * `reactions` maps to the per-emoji `sort:reactions-+1`, NOT the bare `sort:reactions`. GitHub's bare form orders
- * by the total across every reaction type, but the only reaction count on an `IssueShape` is `thumbsUpCount`,
- * which this client fills from `reactions(content: THUMBS_UP)`. Ordering by the total would rank the page by a
- * number the caller cannot see — and would disagree with `getIssueComparator`, which re-sorts a merged page from
- * `thumbsUpCount`, so the same request would order one way with a single relationship and another way with two.
- * `@gitkraken/provider-apis` maps it the same way for the same reason.
- *
- * Absent keys are absent on purpose: `closed` is NOT here even though `IssueShape.closedDate` exists, because
- * GitHub's search cannot order by close date and a client-side sort over a page cut off at the result ceiling is
- * exactly the lie the contract avoids. `sorts` in `githubIssueSearchCapabilities` is the same set, and a parity
- * test pins the two together.
- */
-export const gitHubIssueSortQualifiers: Partial<Record<IssueSorting, string>> = {
-	'created:asc': 'sort:created-asc',
-	'created:desc': 'sort:created-desc',
-	'updated:asc': 'sort:updated-asc',
-	'updated:desc': 'sort:updated',
-	'comments:asc': 'sort:comments-asc',
-	'comments:desc': 'sort:comments-desc',
-	'reactions:asc': 'sort:reactions-+1-asc',
-	'reactions:desc': 'sort:reactions-+1-desc',
-};
-
-/**
- * The `sort:` qualifier for a key, or `undefined` when there is no key or GitHub can't express it.
- *
- * Applies no default of its own: the two callers differ on whether they HAVE one — the filtered search always
- * orders, and `searchMyIssues` has never requested an order at all — so the default belongs at the call site that
- * has one rather than behind a guard at the one that doesn't.
- *
- * `undefined` for an inexpressible key rather than a fallback to something orderable: every caller validated
- * against the declared capability first, so reaching that case means the capability table has outrun this one, and
- * a silently unordered search would change which rows land inside the result ceiling.
- */
-export function toGitHubIssueSortQualifier(sort: IssueSorting | undefined): string | undefined {
-	return sort != null ? gitHubIssueSortQualifiers[sort] : undefined;
-}
-
-/**
- * The sort keys a CEILING SLIDE can continue past, and the qualifier each one continues with.
- *
- * The slide works by re-issuing the search bounded to the far side of what has already been served, which needs
- * two things from the sort key: a value carried on the returned issue (so the boundary can be read off the last
- * item), and a GitHub range qualifier over that same value (so the continuation can be expressed). Only the two
- * date keys have both. `comments`/`reactions` have range qualifiers but their values are unstable under
- * concurrent activity — a comment added mid-walk moves an issue across the boundary, which would drop or repeat
- * it — and `title` has no range qualifier at all. Those keep reporting the ceiling instead, which is correct
- * rather than a gap: the read stays truthful about what it could not reach.
- *
- * A `Partial<Record<…>>` over the union rather than a lookup with a default, so a sort key added later is
- * NOT-slidable by construction and has to be opted in deliberately.
- */
-const gitHubSlidableSortFields: Partial<Record<IssueSortField, string>> = {
-	created: 'created',
-	updated: 'updated',
-};
-
-/**
- * The qualifier that continues a search past the provider's result ceiling: everything at or beyond the last
- * item already served, under the same key the search is ordered by.
- *
- * INCLUSIVE (`<=` / `>=`) rather than exclusive, and that is a correctness requirement rather than a preference.
- * GitHub timestamps have one-second resolution and ties genuinely occur (measured: one shared second in a
- * 100-issue sample), so an exclusive bound would silently drop every issue sharing the boundary second with the
- * last one served. Being inclusive re-serves that second instead, which the caller dedupes.
- *
- * Returns `undefined` when the key can't be slid ({@link gitHubSlidableSortFields}), which is the signal to
- * report the ceiling rather than to continue.
- */
-export function toGitHubIssueSearchSlideQualifier(sort: IssueSorting, boundary: Date): string | undefined {
-	const [field, direction] = sort.split(':') as [IssueSortField, 'asc' | 'desc'];
-	const qualifier = gitHubSlidableSortFields[field];
-	if (qualifier == null) return undefined;
-
-	// Whole seconds, matching both GitHub's own resolution and what its range qualifiers accept.
-	const value = boundary.toISOString().replace(/\.\d{3}Z$/, 'Z');
-	// Descending walks toward older, so the remainder is everything at or BEFORE the boundary; ascending is the
-	// mirror. Getting this backwards would re-request the half already served, forever.
-	return `${qualifier}:${direction === 'desc' ? '<=' : '>='}${value}`;
-}
-
-/**
- * The scope half of an issue search query: `org:` plus one `repo:` per repository.
- *
- * Shared by the search and the count probe rather than written twice, because the count is only meaningful if it
- * applies EXACTLY the qualifiers the search would — a count under different constraints is a wrong number, not a
- * missing one. A value emptied by sanitizing is dropped rather than emitted as a bare `org:`/`repo:`, which
- * GitHub rejects; that is the same rule {@link toGitHubIssueSearchQualifiers} applies to its own values.
- */
-export function toGitHubIssueSearchScopeQualifiers(
-	org: string | undefined,
-	repos: readonly string[] | undefined,
-): string[] {
-	const qualifiers: string[] = [];
-
-	if (org != null) {
-		const value = sanitizeGitHubQualifierValue(org);
-		if (value.length > 0) {
-			qualifiers.push(`org:${value}`);
-		}
-	}
-
-	for (const repo of repos ?? []) {
-		const value = sanitizeGitHubQualifierValue(repo);
-		if (value.length > 0) {
-			qualifiers.push(`repo:${value}`);
-		}
-	}
-
-	return qualifiers;
-}
-
-/**
- * Translates the provider-neutral criteria into GitHub search qualifiers, EXCLUDING the relationship (which
- * becomes its own aliased search, since GitHub AND-s qualifiers and relationships are OR-ed) and excluding the
- * repository/org scope (which {@link toGitHubIssueSearchScopeQualifiers} owns).
- *
- * A `sort:` qualifier is ALWAYS emitted. Never none: the provider serves at most a bounded window of matches, and
- * without an explicit order GitHub answers in relevance order, so which rows land inside that window would shift
- * with GitHub's ranking even when nothing changed upstream. A key GitHub can't express is refused before this by
- * the facade, so it cannot arrive here.
- *
- * `sort` is passed in rather than read off `criteria` so that the qualifier this emits and the key the caller
- * records elsewhere cannot disagree — see `effectiveIssueSort`.
- *
- * Free-form values go through the sanitizers above, and one emptied by sanitizing is dropped rather than emitted
- * as an empty qualifier.
- */
-export function toGitHubIssueSearchQualifiers(criteria: IssueSearchCriteria | undefined, sort: IssueSorting): string[] {
-	const qualifiers = ['type:issue'];
-
-	switch (criteria?.state) {
-		case 'closed':
-			qualifiers.push('is:closed');
-			break;
-		// Every state — no qualifier constrains it.
-		case 'all':
-			break;
-		default:
-			qualifiers.push('is:open');
-			break;
-	}
-
-	if (criteria?.includeArchived !== true) {
-		qualifiers.push('archived:false');
-	}
-
-	// One place to keep the "a value emptied by sanitizing is DROPPED, never emitted as an empty qualifier" rule,
-	// so a criterion added later can't skip it — a bare `milestone:""` is rejected by GitHub outright.
-	const pushSanitized = (value: string | undefined, toQualifier: (sanitized: string) => string): void => {
-		if (value == null) return;
-
-		const sanitized = sanitizeGitHubQualifierValue(value);
-		if (sanitized.length > 0) {
-			qualifiers.push(toQualifier(sanitized));
-		}
-	};
-
-	for (const label of criteria?.labels ?? []) {
-		pushSanitized(label, v => `label:"${v}"`);
-	}
-	pushSanitized(criteria?.milestone, v => `milestone:"${v}"`);
-	pushSanitized(criteria?.updatedAfter, v => `updated:>=${v}`);
-	pushSanitized(criteria?.createdAfter, v => `created:>=${v}`);
-
-	if (criteria?.withoutLinkedPullRequest === true) {
-		qualifiers.push('-linked:pr');
-	}
-
-	if (criteria?.text != null) {
-		const text = sanitizeGitHubSearchText(criteria.text);
-		if (text.length > 0) {
-			qualifiers.push(text);
-		}
-	}
-
-	// Last, where it has always been: the exact-query tests pin the whole qualifier string, not a set.
-	const sortQualifier = toGitHubIssueSortQualifier(sort);
-	if (sortQualifier != null) {
-		qualifiers.push(sortQualifier);
-	}
-
-	return qualifiers;
-}

package/src/plus/git-github/api/pullRequestSearchQuery.ts

@@ -1,154 +0,0 @@
-import type {
-	PullRequestSearchCriteria,
-	PullRequestSorting,
-	PullRequestStateFilter,
-} from '../../../git/models/pullRequest.js';
-import { defaultPullRequestSort, PullRequestFilter } from '../../../git/models/pullRequest.js';
-import { sanitizeGitHubQualifierValue, sanitizeGitHubSearchText } from './issueSearchQuery.js';
-
-export type GitHubPullRequestSearchFacet = {
-	/** Stable GraphQL alias and composite-cursor key. */
-	alias: string;
-	qualifiers: string[];
-};
-
-/**
- * The GitHub search qualifier each relationship translates to. Exhaustive over `PullRequestFilter` so a new
- * member can't be silently unmapped.
- *
- * Exported because the account-wide read builds its own facets from the same vocabulary (see
- * `GitHubIntegrationBase.getProviderMyPullRequestsForUser`). Kept as ONE declaration rather than a copy per
- * caller: the exhaustive `Record` makes a missing key a compile error, but nothing would catch two copies
- * disagreeing on a qualifier STRING, and a wrong qualifier is a read that quietly answers a different question.
- */
-export const gitHubPullRequestRelationshipQualifiers: Record<PullRequestFilter, string> = {
-	[PullRequestFilter.Author]: 'author:@me',
-	[PullRequestFilter.Assignee]: 'assignee:@me',
-	[PullRequestFilter.ReviewRequested]: 'review-requested:@me',
-	[PullRequestFilter.Reviewed]: 'reviewed-by:@me',
-	[PullRequestFilter.Mention]: 'mentions:@me',
-};
-
-const relationshipAlias: Record<PullRequestFilter, string> = {
-	[PullRequestFilter.Author]: 'author',
-	[PullRequestFilter.Assignee]: 'assignee',
-	[PullRequestFilter.ReviewRequested]: 'reviewRequested',
-	[PullRequestFilter.Reviewed]: 'reviewed',
-	[PullRequestFilter.Mention]: 'mention',
-};
-
-const stateAlias: Record<PullRequestStateFilter, string> = {
-	open: 'Open',
-	closed: 'Closed',
-	merged: 'Merged',
-	all: 'All',
-};
-
-/**
- * How each orderable key becomes a GitHub `sort:` qualifier.
- *
- * A literal `Record` over the union rather than a derived transform, for the same reason the relationship tables
- * are: adding a sort field without deciding its qualifier fails the build instead of quietly emitting a search
- * with no ordering constraint — the one failure mode the ordering contract exists to prevent, and the one a
- * caller cannot detect from the result.
- *
- * `updated:desc` maps to the bare `sort:updated`, not `sort:updated-desc`. The two are the same query to GitHub,
- * but the bare form is what this read has always emitted, so keeping it makes the default byte-identical to
- * today's query — matching `toGitHubIssueSortQualifier`. Do not "normalize" it.
- */
-export const gitHubPullRequestSortQualifiers: Partial<Record<PullRequestSorting, string>> = {
-	'created:asc': 'sort:created-asc',
-	'created:desc': 'sort:created-desc',
-	'updated:asc': 'sort:updated-asc',
-	'updated:desc': 'sort:updated',
-};
-
-/** The `sort:` qualifier for a key, or `undefined` when there is no key or GitHub can't express it. */
-export function toGitHubPullRequestSortQualifier(sort: PullRequestSorting | undefined): string | undefined {
-	return sort != null ? gitHubPullRequestSortQualifiers[sort] : undefined;
-}
-
-function stateQualifiers(state: PullRequestStateFilter): string[] {
-	switch (state) {
-		case 'closed':
-			// GitHub's `is:closed` includes merged PRs; `is:unmerged` removes that subset.
-			return ['is:closed', 'is:unmerged'];
-		case 'merged':
-			return ['is:merged'];
-		case 'all':
-			return [];
-		case 'open':
-			return ['is:open'];
-	}
-}
-
-/**
- * Translates provider-neutral PR criteria into the independent GitHub searches whose union answers the request.
- *
- * GitHub's API search syntax ANDs repeated relationship/state qualifiers and does not implement the boolean
- * groups accepted by the newer web UI. Each requested relationship × state pair therefore becomes one GraphQL
- * alias; the API client sends every active alias in a single document, preserving one HTTP request per page.
- * An omitted relationship is the explicitly unfiltered repository/organization scope, never `involves:@me`.
- */
-export function toGitHubPullRequestSearchFacets(
-	criteria: PullRequestSearchCriteria | undefined,
-): GitHubPullRequestSearchFacet[] {
-	const relationships: (PullRequestFilter | undefined)[] = criteria?.relationships?.length
-		? [...new Set(criteria.relationships)]
-		: [undefined];
-	const requestedStates: PullRequestStateFilter[] = criteria?.states?.length
-		? [...new Set(criteria.states)]
-		: ['open'];
-	const states: PullRequestStateFilter[] = requestedStates.includes('all') ? ['all'] : requestedStates;
-	const text = criteria?.text != null ? sanitizeGitHubSearchText(criteria.text) : '';
-	// Ordering is part of the contract, not an option: without an explicit `sort:` GitHub answers in relevance
-	// order, so which rows land inside the result ceiling would shift with its ranking even when nothing changed
-	// upstream. A key GitHub can't express is REFUSED here, not approximated with a fallback order — a silent
-	// `sort:updated` substitute would emit one order in the query while the merged-page comparator applied another
-	// (or none for an unknown field), which is exactly the "the N most recent are what you get" promise the ceiling
-	// contract cannot keep under a guessed order. Unreachable through the facade — every key is validated against
-	// `githubPullRequestSearchCapabilities.sorts` first — so this guards the direct callers of this exported builder
-	// and of `GitHubApi.searchPullRequestsPage`.
-	//
-	// Deliberately STRICTER than the issue path, which drops an inexpressible qualifier and searches on
-	// (`toGitHubIssueSearchQualifiers` pushes `toGitHubIssueSortQualifier`'s result only when it is non-null). The
-	// two reads differ in what that costs: an issue search is served by whichever facets the provider ordered, while
-	// this one hands its merged page to `getPullRequestComparator`, so a dropped qualifier here means the query and
-	// the comparator disagree about the order the ceiling was applied under. Refusing is the only answer that
-	// cannot lie about which rows were reachable.
-	const sort = criteria?.sort ?? defaultPullRequestSort;
-	const sortQualifier = toGitHubPullRequestSortQualifier(sort);
-	if (sortQualifier == null) {
-		throw new Error(`GitHub cannot order a pull request search by '${sort}'`);
-	}
-
-	// Facet-independent, unlike the relationship/state qualifiers below — build once and share.
-	const dateQualifiers: string[] = [];
-	const pushDate = (value: string | undefined, toQualifier: (sanitized: string) => string): void => {
-		if (value == null) return;
-
-		const sanitized = sanitizeGitHubQualifierValue(value);
-		if (sanitized.length > 0) {
-			dateQualifiers.push(toQualifier(sanitized));
-		}
-	};
-	pushDate(criteria?.updatedAfter, v => `updated:>=${v}`);
-	pushDate(criteria?.createdAfter, v => `created:>=${v}`);
-
-	return relationships.flatMap(relationship =>
-		states.map(state => ({
-			alias: `${relationship != null ? relationshipAlias[relationship] : 'scope'}${stateAlias[state]}`,
-			qualifiers: [
-				'is:pr',
-				...(relationship != null ? [gitHubPullRequestRelationshipQualifiers[relationship]] : []),
-				...stateQualifiers(state),
-				// `!= null`, not truthy: `draft:false` narrows to ready-for-review PRs just as `draft:true` narrows to drafts.
-				...(criteria?.draft != null ? [`draft:${criteria.draft}`] : []),
-				...(criteria?.includeArchived === true ? [] : ['archived:false']),
-				...(text.length > 0 ? [text] : []),
-				...dateQualifiers,
-				sortQualifier,
-			],
-		})),
-	);
-}

package/src/plus/git-github/api/token.ts

@@ -1,15 +0,0 @@
-/**
- * Simplified token info for the library.
- * The extension bridges from its `TokenWithInfo` (which depends on `IntegrationIds`)
- * to this VS Code-free representation.
- */
-export interface GitHubTokenInfo {
-	readonly providerId: string;
-	readonly accessToken: string;
-	/** First 3 chars of md5 hash of the token (for logging). */
-	readonly microHash?: string;
-	readonly cloud: boolean;
-	readonly type: string | undefined;
-	readonly scopes?: readonly string[];
-	readonly expiresAt?: Date;
-}

package/src/plus/git-github/api/tokenUtils.ts

@@ -1,15 +0,0 @@
-import type { GitHubSession } from '../context.js';
-import type { GitHubTokenInfo } from './token.js';
-
-/**
- * Converts a {@link GitHubSession} to a {@link GitHubTokenInfo} suitable for API calls.
- */
-export function toTokenInfo(providerId: string, session: GitHubSession): GitHubTokenInfo {
-	return {
-		providerId: providerId,
-		accessToken: session.accessToken,
-		cloud: session.cloud,
-		type: session.type,
-		scopes: session.scopes,
-	};
-}