Repository navigation
[Bug]: http-client-js client options use endpoint when the server parameter has another name #12352
Description
Describe the bug
When the @server parameter is not named endpoint, the options interface still declares endpoint, but the context factory reads the real parameter name from the options. The emitted client does not type-check, and the option cannot be set through the declared type.
Reproduction
Emitted with @typespec/http-client-js (default options).
import "@typespec/http";
using Http;
@service(#{ title: "Repro" })
@server("{baseUrl}", "", { baseUrl?: url = "http://localhost:3000" })
namespace Repro;
@get op read(): void;Actual:
In src/api/reproClientContext.ts:
export interface ReproClientOptions extends ClientOptions {
endpoint?: string;
}
// ...
const params: Record<string, any> = {
baseUrl: options?.baseUrl ?? "http://localhost:3000"
};reproClientContext.ts(15,23): error TS2339: Property 'baseUrl' does not exist on type 'ReproClientOptions'.
Expected: the options interface declares the server parameters by their names (baseUrl?: string).
Versions: @typespec/compiler 1.17.0, @typespec/http 1.17.0, @typespec/http-client-js 0.16.3. Also reproduced with the emitter built from main (721154b).
Checklist
- Follow our Code of Conduct
- Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
- Check that this is a concrete bug. For Q&A open a GitHub Discussion.
- The provided reproduction is a minimal reproducible example of the bug.
Reacted by github-actions
Activity
github-actions commentedon Oct 22, 2026
🎯 Issue Triage
The JS client emitter hardcodes
endpointin the generated options interface but reads the actual@serverparameter name when constructing request parameters. A custom name such asbaseUrltherefore produces invalid TypeScript and cannot be configured through the declared options type.Category: Bug
Area:
emitter:client:js🔗 [Playground Reproduction]((typespec.io/redacted)
📋 Reproduction code
🔍 Analysis
The affected component is
@typespec/http-client-jsclient-context/options generation. The likely cause is that the options interface generation assumes the conventionalendpointproperty while context initialization correctly derivesbaseUrlfrom server parameter metadata. The two generated surfaces must use the same parameter names. Searches for the error, custom server-parameter names, and endpoint option generation found no strong duplicate.📝 Suggested next steps
@serverparameters rather than a hardcodedendpointproperty.guishiw commentedon Oct 30, 2026
Hi, I’d like to work on this issue. I’ve reproduced the problem and completed a proposed fix.