chore(sse): drop deprecated baseUrl from open-sse tsconfig for TS 7.0 readiness by backryun · Pull Request #8473 · diegosouzapw/OmniRoute

backryun · 2026-07-24T21:19:14Z

Problem

open-sse/tsconfig.json is the only tsconfig in the repo that still declares baseUrl. With the pinned TypeScript 6.0.3 this is a hard error, surfaced in-editor on every open-sse file:

open-sse/tsconfig.json(17,5): error TS5101: Option 'baseUrl' is deprecated and will
stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"'
to silence this error.

The existing "ignoreDeprecations": "5.0" no longer covers it — TS 6 demands "6.0". Bumping that string would only re-hide the problem for one more major, so this removes the deprecated option instead.

Change

Drop baseUrl: ".." and rewrite paths relative to the tsconfig's own directory, which is how TypeScript resolves path mappings when no baseUrl is set:

alias	before (resolved via `baseUrl: ".."`)	after
`@/*`	`./src/*`	`../src/*`
`@omniroute/open-sse`	`./open-sse`	`../open-sse`
`@omniroute/open-sse/*`	`./open-sse/*`	`../open-sse/*`

All three still resolve to the same directories. ignoreDeprecations is removed too — baseUrl was the only deprecated option it was suppressing.

Validation (Hard Rule #18 — TDD)

Failing-then-passing guard test: tests/unit/tsconfig-ts7-readiness.test.ts (4 of 5 assertions failed before the fix, 5/5 after).

It asserts no tsconfig reintroduces baseUrl or ignoreDeprecations, and that every paths target still resolves to a real directory. The second half is the load-bearing one: removing baseUrl silently changes what the mappings point at, so a "no baseUrl" check on its own would happily pass a config whose aliases had stopped resolving.

tsc error-set diff

Raw error counts are misleading here — TS5101 is a config-level error that aborts type-checking, so the pre-fix run reported exactly 1 error while masking everything behind it. To get a real comparison the base config was re-run with only ignoreDeprecations flipped to "6.0", letting compilation proceed, and the two full error sets were diffed:

	errors	`TS2307` (unresolved module)
base (`baseUrl: ".."`, `ignoreDeprecations: "6.0"`)	335	3
this PR	307	1

Zero new errors. The 28 that disappeared are all in electron/*.js (main.js 22, loginManager.js 5, lib/resolveNodeHelper.js 1) — files baseUrl: ".." had been pulling into the open-sse program through root-relative resolution. The remaining TS2307 (log-wrapper in comboManifestMetrics.ts) is pre-existing and present in both runs. The 307 are long-standing type errors that were hidden behind the config error; this PR does not touch them and no CI job type-checks against this tsconfig.

--traceResolution confirms aliases still resolve, e.g. @/lib/proxyHealth → src/lib/proxyHealth.ts, @omniroute/open-sse/utils/proxyFamily → open-sse/utils/proxyFamily.ts.

Gates

gate	result
`tests/unit/tsconfig-ts7-readiness.test.ts`	5/5 pass
`npm run typecheck:core`	clean
`npm run check:type-coverage`	pass — 92.17% → 94.01%
`check-type-coverage` / `quality-ratchet` / `check-openapi-breaking-ratchet` unit tests	44/44 pass
`eslint` on changed files	0 errors

One thing to decide

check:type-coverage measures against this exact tsconfig, so narrowing the program lifted it from 92.17% to 94.01%. The ratchet direction is up, so the gate passes and CI is green either way — but I deliberately did not run quality:ratchet --update. The gain comes from excluding untyped electron/*.js, not from new typing work, and re-baselining is a separate call from this fix. Say the word if you want the baseline moved to 94.01 in this PR; leaving it at 92.17 does mean the gate tolerates a drop it otherwise wouldn't.

The rationale comment in scripts/check/check-type-coverage.mjs cited baseUrl as the reason that tsconfig was chosen, so it is updated to match.

TypeScript 6.x raises TS5101 on `open-sse/tsconfig.json`: `baseUrl` is deprecated and stops functioning in TypeScript 7.0. It was paired with `ignoreDeprecations: "5.0"`, which no longer silences it under TS 6 (the compiler now demands "6.0"). Remove `baseUrl: ".."` and rewrite the `paths` mappings relative to the tsconfig's own directory, which is how TypeScript resolves them with no baseUrl set: "@/*" ./src/* -> ../src/* "@omniroute/open-sse" ./open-sse -> ../open-sse "@omniroute/open-sse/*" ./open-sse/* -> ../open-sse/* `ignoreDeprecations` goes with it — baseUrl was the only deprecated option it was suppressing. Verified by diffing the full tsc error set against the previous config (the base run used `ignoreDeprecations: "6.0"` so compilation proceeds past the config error, which otherwise aborts type-checking and masks everything): zero new errors, 28 fewer. All 28 were in `electron/*.js`, which `baseUrl: ".."` had been dragging into the open-sse program via root-relative resolution. Scoping the program back to open-sse also moves `check:type-coverage` from 92.17% to 94.01%; the ratchet direction is up so the gate passes, and the baseline is deliberately left alone because the gain is a measurement-scope change rather than new typing work. The guard test asserts no tsconfig reintroduces `baseUrl` or `ignoreDeprecations`, and that every `paths` target still resolves to a real directory — the second half is the part that matters, since dropping baseUrl silently changes what those mappings point at.

diegosouzapw · 2026-07-25T03:31:36Z

Thanks for this — clean fix and a genuinely useful guard test. I reproduced everything independently: checked out the branch, confirmed the guard test fails against the pre-fix open-sse/tsconfig.json (baseUrl/ignoreDeprecations present, paths broken) and passes 5/5 with your change, and separately ran typecheck:core (clean, untouched by this), check:type-coverage (94.01%, matches your numbers exactly, ratchet direction is up so it's fine as-is), eslint (0 errors) and check:docs-sync (pass). Also confirmed via grep that no other tsconfig in the repo declares baseUrl and nothing besides check-type-coverage.mjs references this tsconfig path, so the blast radius really is contained to the three files you touched.

On your open question: we'll leave the quality-baseline.json re-baseline (92.17 -> 94.01) as a separate maintainer call rather than bundling it here — appreciate you flagging it explicitly instead of quietly rolling it in. Merging as-is.

…ecutor (#8485) `gemini-business.ts` built its upstream fetch options with `combineAbortSignals(...)`, which is defined nowhere in the repository. The module imports `mergeAbortSignals` from `./base.ts` on line 31 and never used it — a rename that was only half applied. Because the call sits inside the fetch options object literal, the ReferenceError was thrown while *constructing* the arguments, before `fetch()` ran, and the surrounding try/catch turned it into `makeErrorResult(502, "Gemini Business network error: ...")`. So every Gemini Business request failed with what reads like an upstream outage. The provider is registered and reachable (`open-sse/executors/index.ts`), so this affects the whole provider, not an edge case. `mergeAbortSignals(primary, secondary)` requires two real signals while `ExecuteInput.signal` is `AbortSignal | null | undefined`, so the call is guarded and falls back to the timeout alone — the same shape huggingchat, grok-web, claude-web, and ninerouter already use. Why it went unnoticed: this file is only type-checked by `open-sse/tsconfig.json`, whose runs abort at `TS5101` (the deprecated `baseUrl`) before any file is checked, and `typecheck:core` covers a curated 26-file allowlist that excludes every executor. Removing that config error is #8473; this bug is what the first full run surfaced. TDD: the two new tests fail on the parent commit — `execute()` never reaches the stubbed `fetch` — and pass with the fix. They also cover the null-signal path, since that is where an unguarded `mergeAbortSignals` would throw next.

diegosouzapw · 2026-07-25T05:53:59Z

Merged into release/v3.8.49 — thanks @backryun! Validated via a 26-PR local merge-train + per-file discriminator confirming zero regressions vs the pure release tip. 🙏

…diegosouzapw#8473) TypeScript 6.x raises TS5101 on `open-sse/tsconfig.json`: `baseUrl` is deprecated and stops functioning in TypeScript 7.0. It was paired with `ignoreDeprecations: "5.0"`, which no longer silences it under TS 6 (the compiler now demands "6.0"). Remove `baseUrl: ".."` and rewrite the `paths` mappings relative to the tsconfig's own directory, which is how TypeScript resolves them with no baseUrl set: "@/*" ./src/* -> ../src/* "@omniroute/open-sse" ./open-sse -> ../open-sse "@omniroute/open-sse/*" ./open-sse/* -> ../open-sse/* `ignoreDeprecations` goes with it — baseUrl was the only deprecated option it was suppressing. Verified by diffing the full tsc error set against the previous config (the base run used `ignoreDeprecations: "6.0"` so compilation proceeds past the config error, which otherwise aborts type-checking and masks everything): zero new errors, 28 fewer. All 28 were in `electron/*.js`, which `baseUrl: ".."` had been dragging into the open-sse program via root-relative resolution. Scoping the program back to open-sse also moves `check:type-coverage` from 92.17% to 94.01%; the ratchet direction is up so the gate passes, and the baseline is deliberately left alone because the gain is a measurement-scope change rather than new typing work. The guard test asserts no tsconfig reintroduces `baseUrl` or `ignoreDeprecations`, and that every `paths` target still resolves to a real directory — the second half is the part that matters, since dropping baseUrl silently changes what those mappings point at.

…ecutor (diegosouzapw#8485) `gemini-business.ts` built its upstream fetch options with `combineAbortSignals(...)`, which is defined nowhere in the repository. The module imports `mergeAbortSignals` from `./base.ts` on line 31 and never used it — a rename that was only half applied. Because the call sits inside the fetch options object literal, the ReferenceError was thrown while *constructing* the arguments, before `fetch()` ran, and the surrounding try/catch turned it into `makeErrorResult(502, "Gemini Business network error: ...")`. So every Gemini Business request failed with what reads like an upstream outage. The provider is registered and reachable (`open-sse/executors/index.ts`), so this affects the whole provider, not an edge case. `mergeAbortSignals(primary, secondary)` requires two real signals while `ExecuteInput.signal` is `AbortSignal | null | undefined`, so the call is guarded and falls back to the timeout alone — the same shape huggingchat, grok-web, claude-web, and ninerouter already use. Why it went unnoticed: this file is only type-checked by `open-sse/tsconfig.json`, whose runs abort at `TS5101` (the deprecated `baseUrl`) before any file is checked, and `typecheck:core` covers a curated 26-file allowlist that excludes every executor. Removing that config error is diegosouzapw#8473; this bug is what the first full run surfaced. TDD: the two new tests fail on the parent commit — `execute()` never reaches the stubbed `fetch` — and pass with the fix. They also cover the null-signal path, since that is where an unguarded `mergeAbortSignals` would throw next.

…diegosouzapw#8473) TypeScript 6.x raises TS5101 on `open-sse/tsconfig.json`: `baseUrl` is deprecated and stops functioning in TypeScript 7.0. It was paired with `ignoreDeprecations: "5.0"`, which no longer silences it under TS 6 (the compiler now demands "6.0"). Remove `baseUrl: ".."` and rewrite the `paths` mappings relative to the tsconfig's own directory, which is how TypeScript resolves them with no baseUrl set: "@/*" ./src/* -> ../src/* "@omniroute/open-sse" ./open-sse -> ../open-sse "@omniroute/open-sse/*" ./open-sse/* -> ../open-sse/* `ignoreDeprecations` goes with it — baseUrl was the only deprecated option it was suppressing. Verified by diffing the full tsc error set against the previous config (the base run used `ignoreDeprecations: "6.0"` so compilation proceeds past the config error, which otherwise aborts type-checking and masks everything): zero new errors, 28 fewer. All 28 were in `electron/*.js`, which `baseUrl: ".."` had been dragging into the open-sse program via root-relative resolution. Scoping the program back to open-sse also moves `check:type-coverage` from 92.17% to 94.01%; the ratchet direction is up so the gate passes, and the baseline is deliberately left alone because the gain is a measurement-scope change rather than new typing work. The guard test asserts no tsconfig reintroduces `baseUrl` or `ignoreDeprecations`, and that every `paths` target still resolves to a real directory — the second half is the part that matters, since dropping baseUrl silently changes what those mappings point at.

…ecutor (diegosouzapw#8485) `gemini-business.ts` built its upstream fetch options with `combineAbortSignals(...)`, which is defined nowhere in the repository. The module imports `mergeAbortSignals` from `./base.ts` on line 31 and never used it — a rename that was only half applied. Because the call sits inside the fetch options object literal, the ReferenceError was thrown while *constructing* the arguments, before `fetch()` ran, and the surrounding try/catch turned it into `makeErrorResult(502, "Gemini Business network error: ...")`. So every Gemini Business request failed with what reads like an upstream outage. The provider is registered and reachable (`open-sse/executors/index.ts`), so this affects the whole provider, not an edge case. `mergeAbortSignals(primary, secondary)` requires two real signals while `ExecuteInput.signal` is `AbortSignal | null | undefined`, so the call is guarded and falls back to the timeout alone — the same shape huggingchat, grok-web, claude-web, and ninerouter already use. Why it went unnoticed: this file is only type-checked by `open-sse/tsconfig.json`, whose runs abort at `TS5101` (the deprecated `baseUrl`) before any file is checked, and `typecheck:core` covers a curated 26-file allowlist that excludes every executor. Removing that config error is diegosouzapw#8473; this bug is what the first full run surfaced. TDD: the two new tests fail on the parent commit — `execute()` never reaches the stubbed `fetch` — and pass with the fix. They also cover the null-signal path, since that is where an unguarded `mergeAbortSignals` would throw next.

backryun requested a review from diegosouzapw as a code owner July 24, 2026 21:19

backryun mentioned this pull request Jul 25, 2026

refactor(sse): restore three executor types the runtime already relied on #8520

Merged

diegosouzapw merged commit 1930b09 into diegosouzapw:release/v3.8.49 Jul 25, 2026
5 checks passed

backryun deleted the chore/ready-for-ts7 branch July 25, 2026 07:48

diegosouzapw mentioned this pull request Jul 28, 2026

Release v3.8.49 #7076

Merged

Navigation Menu

Uh oh!

chore(sse): drop deprecated baseUrl from open-sse tsconfig for TS 7.0 readiness - #8473

chore(sse): drop deprecated baseUrl from open-sse tsconfig for TS 7.0 readiness#8473
diegosouzapw merged 1 commit into
diegosouzapw:release/v3.8.49from
backryun:chore/ready-for-ts7

backryun commented Jul 24, 2026

Uh oh!

diegosouzapw commented Jul 25, 2026

Uh oh!

Uh oh!

diegosouzapw commented Jul 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

backryun commented Jul 24, 2026

Problem

Change

Validation (Hard Rule #18 — TDD)

tsc error-set diff

Gates

One thing to decide

Uh oh!

diegosouzapw commented Jul 25, 2026

Uh oh!

Uh oh!

diegosouzapw commented Jul 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants