Easy local backend env var #3116
Conversation
|
hassoncs
force-pushed
the
easy-local-backend-env-var
branch
4 times, most recently
from
faf3d24 to
70d8b45
Compare
hassoncs
force-pushed
the
easy-local-backend-env-var
branch
from
70d8b45 to
e9abdd1
Compare
hassoncs
force-pushed
the
easy-local-backend-env-var
branch
from
e9abdd1 to
88e66d1
Compare
There was a problem hiding this comment.
lgtm. My only question (more for my knowledge), our telemetry client doesn't support this or the o.g. method. Guessing thats because we don't want to accidentally send events while cruising around during development:
Is there a scenario where you'd specify a development KILOCODE_POSTHOG_API_KEY and then still want to use a local backend?
| import * as os from "os" | ||
| import { KiloCodePaths } from "../../utils/paths.js" | ||
| import { logs } from "../logs.js" | ||
| import { getKiloUrl } from "../../../../src/shared/kilocode/url.js" |
There was a problem hiding this comment.
would it be better to add this to the types package?
There was a problem hiding this comment.
Maybe... I just hate putting non-type code in that package, but it is the only reasonable shared package we have. But there's already some code in there so might as well 🤷
src/shared/kilocode/url.ts
Outdated
| * In development: maps subdomains to paths (api.kilocode.ai → localhost:3000/api) | ||
| * In production: preserves subdomain structure (api.kilocode.ai → api.kilocode.ai) | ||
| */ | ||
| export function getKiloUrl(targetUrl: string = "https://kilocode.ai"): string { |
There was a problem hiding this comment.
Can we avoid the hostname parsing by having multiple functions?
getApiUrl(relativePath: string)
getAppUrl(relativePath: string)
Add KILOCODE_BACKEND_BASE_URL environment variable to enable testing against a local Kilo Code backend. Refactor hardcoded API URLs across providers, webview, and CLI to use getKiloUrl() and getKiloUrlFromToken() functions for dynamic URL resolution. Include new launch configuration and documentation updates for local development workflow.
Replace the generic getKiloUrl function with two specific functions: - getApiUrl for API endpoints (e.g., /extension-config.json) - getAppUrl for app/web URLs (e.g., /profile, /support) This improves type safety and clarity by separating concerns between API and app URL generation. BREAKING CHANGE: getKiloUrl function removed, use getApiUrl or getAppUrl instead
Move getApiUrl, getAppUrl, and getKiloUrlFromToken functions from src/shared/kilocode/ to packages/types/src/kilocode/kilocode.ts and update all imports across the codebase. This consolidates shared utilities into the types package, reducing duplication and improving maintainability.
hassoncs
force-pushed
the
easy-local-backend-env-var
branch
from
88e66d1 to
81f1892
Compare
- Introduce getExtensionConfigUrl function for extension config endpoint - Refactor getApiUrl and getAppUrl to use shared buildUrl helper - Update tests to cover new function and maintain backwards compatibility - Use getExtensionConfigUrl in Gemini CLI provider instead of hardcoded URL
| import * as yaml from "yaml" | ||
| import { z } from "zod" | ||
| import { getKiloBaseUriFromToken } from "@roo-code/types" // kilocode_change | ||
| import { getApiUrl } from "@roo-code/types" |
There was a problem hiding this comment.
Should we add kilocode_change here?
| function getGlobalKilocodeBackendUrl(): string { | ||
| return ( | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| (typeof window !== "undefined" ? (window as any).KILOCODE_BACKEND_BASE_URL : undefined) || |
There was a problem hiding this comment.
I think there's a way to extent a type in TypeScript
| const baseUrl = getKiloBaseUriFromToken(kilocodeToken) | ||
| const target = new URL(targetUrl) | ||
|
|
||
| const { protocol, hostname, port } = new URL(baseUrl) |
There was a problem hiding this comment.
Can we get rid of the hostname here as well?
3 participants
This PR builds off my original one, but adds a nice api so the code around most urls looks similar to before:
#3055
With this change, it's super easy to point a local Kilo development extension at a local backend just by changing the run target. This PR does not remove support for the kilocodeToken approach to changing the backendUrl– that's useful for pointing the production extension at local backends