@effected/github 0.4.0 → 0.4.2

package/GitHubIssue.js

@@ -107,6 +107,30 @@ var GitHubIssue = class GitHubIssue extends Context.Service()("@effected/github/
 const unstubbed = (member) => {
 	throw new Error(`GitHubIssue.makeTest: ${member}() was called but not stubbed — pass an override.`);
 };
+/**
+* The REST calendar version this module's requests pin.
+*
+* @remarks
+* The routes are not deprecated — the **default api-version** is. When no
+* `x-github-api-version` header is sent (octokit sends none), GitHub serves
+* calendar version 2022-11-28, which it deprecated when 2026-03-10 shipped and
+* sunsets on 2028-03-10. Every response from an endpoint the new version
+* changed then carries a `Deprecation` header, which `@octokit/request` prints
+* straight to the consumer's console — the constructor's `log` option cannot
+* silence it, because the fetch wrapper resolves `request.log ?? console`.
+* `PATCH /repos/{owner}/{repo}/issues/{issue_number}` is on that list (the
+* singular `assignee` parameter was removed), so every `close` warned once per
+* issue in consumer workflow logs (effected#189).
+*
+* Nothing this module sends or reads changed in 2026-03-10: `state` and
+* `state_reason` are untouched, and the projections read only fields both
+* versions carry. Pinning the current version is therefore the whole fix, and
+* it deliberately does **not** hide future deprecations — when GitHub
+* deprecates 2026-03-10 in turn, the header comes back and octokit warns
+* again. Verified live 2026-08-14: the pinned request answers with no
+* `Deprecation`/`Sunset` headers.
+*/
+const API_VERSION_HEADERS = { "x-github-api-version": "2026-03-10" };
 /** GitHub sends a label as either a string or an object; callers want the name. */
 const labelNames = (labels) => labels.flatMap((label) => typeof label === "string" ? [label] : label.name !== void 0 ? [label.name] : []);
 const project = (raw) => IssueInfo.make({
@@ -128,7 +152,8 @@ const make = (client) => ({
 		const raw = yield* client.request("GET /repos/{owner}/{repo}/issues/{issue_number}", {
 			owner,
 			repo,
-			issue_number: number
+			issue_number: number,
+			headers: API_VERSION_HEADERS
 		});
 		return project(raw);
 	}),
@@ -142,7 +167,8 @@ const make = (client) => ({
 			owner,
 			repo,
 			...options?.state !== void 0 ? { state: options.state } : {},
-			...options?.labels !== void 0 ? { labels: options.labels.join(",") } : {}
+			...options?.labels !== void 0 ? { labels: options.labels.join(",") } : {},
+			headers: API_VERSION_HEADERS
 		}, options?.page)).map(project);
 	}),
 	close: Effect.fn("GitHubIssue.close")(function* (number, reason) {
@@ -157,7 +183,8 @@ const make = (client) => ({
 			repo,
 			issue_number: number,
 			state: "closed",
-			...reason !== void 0 ? { state_reason: reason } : {}
+			...reason !== void 0 ? { state_reason: reason } : {},
+			headers: API_VERSION_HEADERS
 		});
 	}),
 	comment: Effect.fn("GitHubIssue.comment")(function* (number, body) {
@@ -171,7 +198,8 @@ const make = (client) => ({
 			owner,
 			repo,
 			issue_number: number,
-			body
+			body,
+			headers: API_VERSION_HEADERS
 		})).id;
 	}),
 	linkedIssues: Effect.fn("GitHubIssue.linkedIssues")(function* (prNumber) {

package/index.d.ts

@@ -1165,6 +1165,15 @@ interface CodeScanningShape {
    * The endpoint answers **202 Accepted** and configures asynchronously.
    * Nothing here polls: a successful call means GitHub accepted the request,
    * not that scanning is running.
+   *
+   * **Turning it back off does not undo everything it did.** Setting `state`
+   * to `not-configured` stops default setup, but the synthetic CodeQL workflow
+   * GitHub created when it was enabled **survives** — it remains listed among
+   * the repository's workflows afterwards. A caller that treats "default setup
+   * is off" as "no CodeQL workflow exists" will be wrong, and one that counts
+   * workflows to decide whether a repository has any CI will count that one.
+   * Reported by `@spencerbeggs/reposets` (dogfood round 8, 2026-08-14) from a
+   * real organization, not inferred from the API description.
    */
   readonly configure: (setup: CodeScanningSetup) => Effect.Effect<void, GitHubError, Repo>;
   /**
@@ -2827,6 +2836,18 @@ interface RepositoryVariableShape {
    * `notFound` is absorbed — a 403 from a mis-scoped token still fails, where
    * treating any error as absence would turn a permissions problem into a
    * spurious create.
+   *
+   * **The 404-for-absent behaviour is documented, not probed.** Neither this
+   * suite nor the first consumer's has issued this read against real GitHub —
+   * both run against doubles.
+   *
+   * Only `notFound` selects the create branch: a successful read selects the
+   * update branch, and any other failure propagates rather than being guessed
+   * at. So if GitHub answers something *other* than 404 for an absent
+   * variable, the write does not silently take the wrong branch — it either
+   * `PATCH`es a variable that is not there, or fails with the error GitHub
+   * actually sent. Read either as evidence about this assumption rather than
+   * about the caller.
    */
   readonly set: (name: string, value: string) => Effect.Effect<void, GitHubError, Repo>;
   /** The repository's variables, with their values. */

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@effected/github",
-	"version": "0.4.0",
+	"version": "0.4.2",
 	"private": false,
 	"description": "Typed GitHub REST and GraphQL services over the octokit core request surface, with app auth and resource helpers.",
 	"keywords": [