Skip to content

Bundler-injected defaults override explicit ClientEventBus config #499

Description

@kolaworld

TanStack Devtools version

@tanstack/devtools-event-bus: 0.4.2 | @tanstack/devtools-vite: 0.8.3

Framework/Library version

@tanstack/svelte-devtools: 0.1.3

Describe the bug and the steps to reproduce it

ClientEventBus accepts explicit port, host, and protocol options, but a Vite or Rspack connection transform can override them. The constructor passes each explicit option through getDefault*() after destructuring client.ts#L91-L105.

The Vite connection-injection plugin replaces every __TANSTACK_DEVTOOLS_*__ placeholder with the bundler's connection value plugin.ts#L576-L608. After that transform, each getDefault*() helper always returns the injected value, even when the caller supplied a different runtime value. For example, new ClientEventBus({ host: 'devtools.example.com', port: 443, protocol: 'https' }) can still connect to the injected localhost HTTP endpoint.

This prevents applications behind a development proxy from directing the browser event bus through the public HTTPS origin. The client instead attempts to connect to the bundler's internal host, port, and protocol.

Expected behavior

Explicit ClientEventBus options should take precedence over bundler-injected defaults. Bundler-injected values should apply when an option is omitted, and the built-in localhost:4206 HTTP values should remain the final fallback.

The constructor can preserve that precedence by resolving each injected default in the parameter default and assigning an explicitly supplied value directly.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

https://stackblitz.com/edit/vitejs-vite-nz7smy9p?file=package.json,index.html,vite.config.ts,src%2Fmain.ts

Do you intend to try to help solve this bug with your own PR?

Yes, I am also opening a PR that solves the problem along side this issue

Terms & Code of Conduct

  • I agree to follow this project's Code of Conduct
  • I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions