@gitkraken/core-gitlens 0.5.116 → 0.7.0

package/CHANGELOG.md

@@ -6,6 +6,35 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 ## [Unreleased]
 
+## [0.7.0] - 2026-09-22
+
+### Fixed
+
+- Rejects a provider response that carries an HTML page under a success status instead of handing it on as data. Azure DevOps answers a rejected credential by redirecting to its sign-in page, which then returns `203 text/html` rather than `401`, and `response.ok` spans the whole 200-299 range — so the page was read as the body and passed to provider code typed as the JSON it is not. It surfaced as an opaque `TypeError` deep inside a provider, or as nothing at all on a route returning `void`, which made a bad credential look like a successful write. Such a response now raises `UnexpectedHtmlResponseError`. On Azure DevOps, the one provider known to answer a rejected credential this way, it is classified as an authentication failure so a fan-out reports what it actually was; on every other provider it stays a request failure, because a 2xx page there is far more likely a maintenance or WAF interstitial and calling that an auth failure would expire a valid cloud session and count against the budget that disconnects the integration. A page mislabelled as JSON is caught the same way, since `<` can never open valid JSON, and content types are matched case-insensitively as the spec requires. An empty body is exempt, since a write answering `204` can carry a stale `text/html` from its endpoint's usual responses and a sign-in page is never empty. The response attached to the error is stripped of its credential-bearing headers (the session cookie Azure sets, the challenges whose payload names the tenant) and its body cut to a diagnostic prefix, because an error is something a consumer may reasonably log or forward. Azure DevOps' own REST client takes the same guard on its direct reads, where the page previously reached `rsp.json()` and died as a bare `SyntaxError` that every caller reported as a missing work item. An `AuthenticationError` now propagates out of every one of those reads — the work-item and linked issue-or-PR lookups, the PR-for-branch and PR-for-commit reads, the current-user read, the repository-metadata and default-branch probes, which degrade quietly on a 404 by design but must not on a rejected credential, and the work-item state-list read, whose empty-list fallback was cached and so pinned every work item of that type to an unknown state long after the session recovery should have run. Everything else keeps its existing degrade-to-undefined behavior. A non-2xx keeps its own status error, which says more
+- Stops pre-encoding the Azure DevOps credential now that `@gitkraken/provider-apis` 0.59.0 encodes it. That release made `isPAT` produce a real HTTP Basic header, `base64(':' + token)`, where it previously emitted the token verbatim after `Basic ` — so every caller had to encode the pair itself, as this package did via `convertTokentoPAT`. Left alone, the secret would have been encoded twice and refused by Azure DevOps on every SDK-backed read; the raw secret is now handed over and provider-apis encodes it. The one observable change is the Basic username, which goes from `PAT` to empty — the form Azure DevOps documents and the SDK verified live. Azure DevOps' own REST paths in this package build their header directly and are unaffected, as is `getCurrentUser`, which asks for a bearer token
+- Fixes account-wide GitHub issue reads ignoring `itemsPerPage`. The facade dropped the requested size before `searchMyIssues`, so its three aliased searches defaulted to 100 full issue nodes and could exceed GitHub's GraphQL complexity limit. The page size now reaches every alias; omitted values keep the existing 100-item default. (plus/integrations, plus/git-github)
+
+### Added
+
+- Adds Jira Server/Data Center as a self-hosted issue integration, `jira-server` ([#5864](https://github.com/gitkraken/vscode-gitlens/issues/5864)). It is the first id that is both an issue tracker and bound to a customer-run host, so the two properties are no longer fused: `IssuesSelfManagedHostIntegrationId` names the new family and the host-keyed machinery (integration and secret keys, the `connected:${id}:${domain}` flag, domain normalization, per-host primary selection, multi-account reconcile) moves to `isSelfManagedHostIntegrationId`, which spans both families, while `isGitSelfManagedHostIntegrationId` stays exactly where a read goes on to ask for repositories, pull requests or a git remote. `IntegrationKey`/`IntegrationConnectedKey` widen to match. A self-hosted instance is modelled as its own single synthetic resource, which keeps the resource → project contract of `IssuesIntegration` intact so `listOrgs`, `listProjects` and `listIssueTrackerIssuesPage` work unchanged; `listIssueTrackerIssuesPage` gains the `domain` its siblings already took. Every read is addressed to the connection's own base URL, and `ProviderAuthenticationSession` gains an optional `baseUrl` carrying the address exactly as configured: `domain` is the identity a self-managed connection is keyed by and is normalized to a bare host, so an instance mounted below a context path (`https://jira.example.com/jira`) was previously addressed at the root. The new field is populated from the wire domain on both cloud-session paths, mirrored onto `ConfiguredIntegrationDescriptor` so reconciliation can tell a re-pointed connection from an unchanged one without reading its secret (a routine check-in now re-fetches a connection whose address moved, which a normalized domain alone cannot see, refreshes the warm integration so it re-resolves rather than staying on the old path, and keys the Jira Server project cache by the address it read from rather than by host and token, which a same-token move cannot distinguish). A backend response that reports no domain keeps the address already configured rather than writing none, so a refresh cannot silently drop a context path the user never changed, and refused when it names a different host than the connection's key; `baseUrlFromDomain` (the path-preserving sibling of `hostFromDomain`) builds the URL and is now shared rather than private to `gitHostIntegration.ts`. The account-wide "my issues" read reports `truncated` when it stops at its page backstop or on a continuation the server never advances, instead of publishing the prefix as a complete account. The host guard on a self-managed cloud session now refuses only a session that NAMES a different host, and only when the fetch was scoped by a connection id WE have stored for that host (a caller-supplied or stale id is not evidence, and neither is the absence of one): the backend may return no domain at all (`toSession` defaults it to `''`), and treating that as a mismatch stranded the refresh and left the connection looking permanently disconnected — but an UNSCOPED fetch reaches the provider-global primary endpoint, whose token can belong to any configured host, so a domainless response is still refused there rather than being bound to whatever domain the caller asked for. `Integration.icon` now reports `providersMetadata.iconKey` rather than the integration id, which is what that field documents itself as and what every consumer rendering a `gl-provider-<key>` glicon needs: Jira Data Center draws with Jira's glyph, and the self-managed GitHub and GitLab ids now report the keys their metadata declares instead of ids the icon registry has no entry for. The Commit Graph's issue-integration check enumerates every configured host for a self-managed tracker rather than asking a single resolved instance, so one disconnected host no longer disables issue enrichment while another stays connected. Project issue reads address the project by its numeric id rather than its display name, since JQL resolves a `project = "<value>"` clause against key before name and a name colliding with another project's key would read that project's issues. A key that names no issue is reported as a lookup miss rather than a request failure, matching Jira Cloud's `getJiraIssueByKey` and the generic `getIssue`. Branch-association identifiers encode the host and project, since two self-hosted instances routinely issue the same issue keys; decoding one back is not wired up yet, because the resolver behind it takes no domain and would answer from whichever connection is primary
+- Adds `IssueShape.iterations` and `Issue.iterations` so consumers can access Jira sprints and Azure work-item iterations, preserving provider-reported activity and dates without inventing metadata for Azure. Coverage varies per read, and an absent value means the read couldn't report one rather than that the issue has no sprint — see "Sprints and iterations" in `docs/integrations.md`. Azure's iteration reaches both the direct work-item read, parsed here from `System.IterationPath`, and the SDK-backed reads, which requires `@gitkraken/provider-apis` 0.59.0 for the `iteration` field it normalizes; the direct read mirrors that normalization exactly — the path is the identity and is kept verbatim, so one work item cannot end up with two identities depending on which read surfaced it ([#5856](https://github.com/gitkraken/vscode-gitlens/issues/5856)).
+
+## [0.6.0] - 2026-09-14
+
+### Added
+
+- **Breaking (plus/integrations)** — Adds `PullRequestRef.cloneHttps` to an Azure DevOps pull request, on both refs ([#5851](https://github.com/gitkraken/vscode-gitlens/issues/5851)). Azure filled neither clone field on the direct read, so a consumer that turns a ref into a git remote — or matches one against a configured remote — silently fell back for every Azure pull request: a cross-repository pull request never got its fork remote, and a fork head could not be correlated to a local repository. The URL was in hand all along: the pull request payload carries the base repository's `remoteUrl`, and the fork lookup the head ref already pays for returns one too, which was read but discarded whenever `webUrl` was present. Both are now reported, restricted to the integration's collection through the same trust boundary as every other Azure repository URL ([#5842](https://github.com/gitkraken/vscode-gitlens/issues/5842)) and stripped of the credentials Azure spells into a remote URL, so nothing new reaches a `git fetch`. The base ref's is additionally cross-checked against the repository the payload itself names — it is the one repository URL that is READ rather than built, and a URL under the right collection may still name a different repository in it, which would leave `cloneHttps` describing one repository while `url` describes another. Azure ends a clone URL with `_git/{repo}` on every host style, including the short form it uses when a repository carries its project's name and the legacy `{owner}.visualstudio.com` spelling, so the repository name is compared (decoded, case-insensitively, as Azure resolves it) and anything else is refused. No extra request is made on either path. Best-effort by contract, like `refs.*.url`: a payload that reports no `remoteUrl`, or one that names a host or organization the integration never asked for, leaves the field `undefined` rather than having a URL synthesized for it. `cloneSsh` stays unset on this path — Azure's SSH URL answers on a different host than the API base and is not an `http(s)` URL, so the collection check cannot vouch for it — which means `toProviderRemoteInfo`, which requires both fields, still reports no remote info for a pull request read this way; the SDK-backed reads, which carry both fields behind `includeRemoteInfo`, are unchanged. `fromAzurePullRequest`'s fifth parameter is now the resolved fork's `{ url, cloneHttps }` rather than its URL alone, and `sanitizeAzureRepositoryUrl` takes the value as these payloads carry it (`string | undefined`), so no call site spells the absent case itself (plus/integrations)
+- Adds `IssueShape.bodyFormat`, saying which markup `body` is written in ([#5835](https://github.com/gitkraken/vscode-gitlens/issues/5835)). A Jira description arrives from REST v2 as wiki markup while GitHub, GitLab and Linear descriptions are Markdown, and nothing in the model told the two apart — so a consumer rendering `body` as Markdown rendered Jira's `h2.` and `{code}` verbatim. Jira issues now set `bodyFormat: 'jira-wiki'`; an omitted `bodyFormat` means Markdown, which is what every consumer already assumed, so nothing changes for a consumer that ignores the field. Rendering and conversion stay consumer concerns — the package neither converts the Jira body nor returns it as ADF (git, plus/integrations)
+- Adds the provider's own workflow state to a tracker issue as `IssueShape.providerState` ([#5834](https://github.com/gitkraken/vscode-gitlens/issues/5834)). `state` stays the normalized `'opened' | 'closed'` value every existing consumer reads; the new optional field carries what the provider itself calls the state — Jira's status, Linear's workflow state, a Trello list, an Azure DevOps work-item state — with its `name` untranslated, its `color` when the provider sends one, and its `category` (`TO_DO` / `IN_PROGRESS` / `DONE`) only where the provider supplies one that can be trusted. It is display data, so it is NOT added to `IssueOrPullRequest`, whose normalized pull request states are already complete. Jira's legacy reads classify a localized status name and are therefore reported without a category; the direct issue-by-key read maps Jira's stable status-category key itself and keeps it. Per-provider behavior is documented in the consumer guide (git, plus/integrations)
+
+### Changed
+
+- Fixes repository-scoped Azure DevOps Server reads when the server is mounted below one or more virtual directories ([#5847](https://github.com/gitkraken/vscode-gitlens/issues/5847)). The Azure remote provider now finds the repository at the `_git` boundary, reports the collection as `owner`, keeps `project/_git/repository` as `name`, and carries the preceding virtual-directory path separately. The integration appends that path to the authenticated server base URL before reading pull requests, linked issues, commit authors, default branches or repository metadata, so `https://server/tfs/DefaultCollection/Project/_git/Repo` addresses `https://server/tfs/DefaultCollection/Project/_apis/...` rather than treating `tfs` as the collection and `_git` as the repository. Malformed descriptors now fail before any request is sent (git, plus/integrations)
+- **Breaking (git, plus/integrations)** — Fixes `PullRequest.refs.base.url` and `refs.head.url` escaping as `undefined` for every Azure DevOps pull request ([#5839](https://github.com/gitkraken/vscode-gitlens/issues/5839)). Azure embeds an ABBREVIATED repository reference in a pull request — no `webUrl`, `size`, `sshUrl`, `isDisabled` or `isInMaintenance`, and `remoteUrl` only sometimes — but `AzurePullRequest.repository` and `AzureGitForkRef.repository` were typed as the full `GET .../_apis/git/repositories/{id}` response and `webUrl` was read unconditionally, so both ref URLs were `undefined` behind a required `string`. The nested references are now typed as what Azure actually sends (`AzureRepositoryReference`, `AzurePullRequestRepository`), and every repository URL the model reports is BUILT from the prefix the pull request was read through — the API base URL plus the organization, which is exactly what each request is addressed to (`{baseUrl}/{owner}/{project}/_apis/…`) — plus the project and repository names the payload carries, so the common path costs no extra request. `PullRequestRef.url` is now `string | undefined`: only a cross-repository (fork) pull request needs a lookup, because a fork reference carries no project to build from, and that lookup is best-effort — a fork the token cannot read or one that is gone leaves the head ref's `url` unset rather than dropping the pull request, and is retried after five minutes, while a throttled or failed request is retried on the next read. A consumer that turns the URL into a git remote or matches it against one must handle the absent case, which was ALREADY the runtime value on this provider. `fromAzurePullRequest` now takes the organization and the base URL it was read through, plus the resolved fork URL as a REQUIRED fifth parameter (pass `undefined` when there is none), so a new mapping site cannot quietly ship a head ref with no URL; `getAzurePullRequestWebUrl` takes the same base URL and organization. The unused `getAzureOwner` and the duplicate `parseAzureHttpsUrl` this file carried are gone — `packages/git`'s remains. Consumers that directly type these nested Azure payloads must stop reading the removed full-repository fields and handle the optional `remoteUrl` (git, plus/integrations)
+- **Breaking (plus/integrations)** — Fixes an Azure DevOps Server URL behind a virtual directory losing the collection ([#5840](https://github.com/gitkraken/vscode-gitlens/issues/5840)). The organization was read as the FIRST path segment of the pull request's own URL, so `https://server/tfs/DefaultCollection/…` was read as organization `tfs` and every segment in between was dropped. Reading it out of that URL at all was the mistake: an API URL spells only names, so a collection that shares its project's name cannot be told from the project, and neither can an organization whose first project carries its name — which is Azure's default. The prefix is no longer recovered, it is TAKEN: `{baseUrl}/{owner}` is what every request for the pull request was built from, so it already spells the organization on the cloud host and the collection, behind any virtual directory, on Azure DevOps Server. `PullRequest.repository.owner` and `refs.*.owner` are that same organization, so the owner the model reports and the URL it points at cannot disagree. This CHANGES `PullRequest.url`, both `refs.*.url` and those owner fields for a pull request read from such a server — they were wrong before, so a consumer resolving by literal URL equality, or keying identity on owner, must migrate stored values (plus/integrations)
+- **Breaking (plus/integrations)** — Fixes an Azure DevOps pull request's repository URLs being able to name a host or an organization the integration never agreed to talk to ([#5842](https://github.com/gitkraken/vscode-gitlens/issues/5842)). The base and head ref URLs were built from the `url` the payload itself carried, with no check that its host was the configured one, and `sanitizeAzureRepositoryUrl` compared only the ORIGIN — but an Azure DevOps organization is a path segment, so every organization on `dev.azure.com` shares one origin, and every collection on a self-hosted server shares one with all the others. These URLs are not merely rendered: `refs.head.url` reaches `setupPullRequestBranch`, which offers to add a git remote and FETCH from it. Repository URLs are now built from the configured base URL and organization rather than from the payload, so the payload cannot move them at all; the one URL that still comes from the provider — a fork's — must now sit under `{baseUrl}/{owner}`, with the legacy `{owner}.visualstudio.com` spelling of the same organization still accepted, and is refused otherwise. A fork in another organization was never resolvable anyway, because the lookup behind it is scoped to `{baseUrl}/{owner}/_apis/…`; `refs.head.owner` is therefore the same organization as `refs.base.owner` (plus/integrations)
+- **Breaking (plus/integrations)** — Fixes `getAzurePullRequestWebUrl` emitting a malformed Azure DevOps pull request web URL ([#5836](https://github.com/gitkraken/vscode-gitlens/issues/5836)). It built the URL by concatenation, so `new URL(origin).toString()` — which already ends in a slash — produced a double slash after the host on BOTH host styles (`dev.azure.com` and `*.visualstudio.com`), and the project and repository names were interpolated verbatim, so a name containing a space (which Azure permits) put a literal space in the path. Neither spelling is one any two consumers normalize the same way, which is the point: the URL is the identity. It is now built from `origin` directly with each name percent-encoded as its own segment. This CHANGES the `url` of every Azure pull request the package returns — `PullRequest.url` via `fromAzurePullRequest`, and the point read behind `getProviderLinkedIssueOrPullRequest`. A consumer that persisted the old spelling and resolves by literal URL equality will stop matching its stored values at the upgrade and must migrate them; identity keyed on the repository and pull request ids is unaffected (plus/integrations)
+
 ## [0.5.116] - 2026-09-09
 
 ### Changed
@@ -325,7 +354,9 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 - Initial release. Bundles `@gitlens/utils`, `@gitlens/git`, `@gitlens/git-cli`, `@gitlens/ai`, and `@gitlens/git-github` into a single core npm package with subpath exports.
 
-[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.116...HEAD
+[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.0...HEAD
+[0.7.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.6.0...gitkraken:releases/core/v0.7.0
+[0.6.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.116...gitkraken:releases/core/v0.6.0
 [0.5.116]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.115...gitkraken:releases/core/v0.5.116
 [0.5.115]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.114...gitkraken:releases/core/v0.5.115
 [0.5.114]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.113...gitkraken:releases/core/v0.5.114

package/README.md

@@ -28,7 +28,7 @@ import type { GitHubGitProviderInternal } from '@gitkraken/core-gitlens/plus/git
 import { OpenAIProvider } from '@gitkraken/core-gitlens/plus/ai/providers/openaiProvider.js';
 ```
 
-All exports are fully typed and source-mapped back to the original TypeScript sources shipped in `src/`.
+All exports are fully typed and source-mapped, with the original TypeScript sources embedded in the maps.
 
 ### Provider integrations
 
@@ -61,4 +61,11 @@ Independent from the [GitLens VS Code extension](https://github.com/gitkraken/vs
 
 ## Source
 
-Built from the `packages/` workspace of [vscode-gitlens](https://github.com/gitkraken/vscode-gitlens). See `packages/core/scripts/bundle.mjs` in that repo for the flattening logic.
+Built from the `packages/` workspace of [vscode-gitlens](https://github.com/gitkraken/vscode-gitlens), by `pnpm --filter @gitkraken/core-gitlens run build` in two steps:
+
+1. **`tsdown.config.ts`** compiles the eight packages' TypeScript sources straight into `dist/`, one emitted module per source module, each rooted at the subpath in the table above. It reads their `src/` directly — the packages' own manifests resolve to source, so nothing here waits on their `dist/` — and cross-package imports come out as relative paths, with `#env/*` staying external for the `"imports"` field to resolve.
+2. **`scripts/bundle.mjs`** assembles everything around that: it copies the LICENSEs and generates the manifest's `exports`, `imports`, and `dependencies` from the eight sub-packages' own manifests.
+
+Neither the subpath layout nor the generated manifest is hand-written, so adding or removing a bundled package is a one-line change to `scripts/packages.mjs`, which both steps read.
+
+The declaration files are emitted by the TypeScript compiler against `tsconfig.core-dts.json` at the repo root. That config sits at the root rather than beside this package because the emitter uses its directory as the compiler's `rootDir`, which has to contain every bundled source.

package/dist/_virtual/@oxc-project+runtime/helpers/esm/decorate.js

@@ -0,0 +1,9 @@
+//#region \0@oxc-project+runtime@0.148.0/helpers/esm/decorate.js
+function __decorate(decorators, target, key, desc) {
+	var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+	if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+	else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+	return c > 3 && r && Object.defineProperty(target, key, r), r;
+}
+//#endregion
+export { __decorate as default };

package/dist/_virtual/@oxc-project+runtime/helpers/esm/usingCtx.js

@@ -0,0 +1,57 @@
+//#region \0@oxc-project+runtime@0.148.0/helpers/esm/usingCtx.js
+function _usingCtx() {
+	var r = "function" == typeof SuppressedError ? SuppressedError : function(r, e) {
+		var n = Error();
+		return n.name = "SuppressedError", n.error = r, n.suppressed = e, n;
+	}, e = {}, n = [];
+	function using(r, e) {
+		if (null != e) {
+			if (Object(e) !== e) throw new TypeError("using declarations can only be used with objects, functions, null, or undefined.");
+			if (r) var o = e[Symbol.asyncDispose || Symbol["for"]("Symbol.asyncDispose")];
+			if (void 0 === o && (o = e[Symbol.dispose || Symbol["for"]("Symbol.dispose")], r)) var t = o;
+			if ("function" != typeof o) throw new TypeError("Object is not disposable.");
+			t && (o = function o() {
+				try {
+					t.call(e);
+				} catch (r) {
+					return Promise.reject(r);
+				}
+			}), n.push({
+				v: e,
+				d: o,
+				a: r
+			});
+		} else r && n.push({
+			d: e,
+			a: r
+		});
+		return e;
+	}
+	return {
+		e,
+		u: using.bind(null, !1),
+		a: using.bind(null, !0),
+		d: function d() {
+			var o, t = this.e, s = 0;
+			function next() {
+				for (; o = n.pop();) try {
+					if (!o.a && 1 === s) return s = 0, n.push(o), Promise.resolve().then(next);
+					if (o.d) {
+						var r = o.d.call(o.v);
+						if (o.a) return s |= 2, Promise.resolve(r).then(next, err);
+					} else s |= 1;
+				} catch (r) {
+					return err(r);
+				}
+				if (1 === s) return t !== e ? Promise.reject(t) : Promise.resolve();
+				if (t !== e) throw t;
+			}
+			function err(n) {
+				return t = t !== e ? new r(n, t) : n, next();
+			}
+			return next();
+		}
+	};
+}
+//#endregion
+export { _usingCtx as default };