TanStack Devtools version

@tanstack/svelte-devtools: 0.1.3

Framework/Library version

Svelte: 5.56.5 | @sveltejs/vite-plugin-svelte: 7.1.4 | Vite: 8.0.9

Describe the bug and the steps to reproduce it

@tanstack/svelte-devtools has two related published-package problems when consumed by a standard Svelte Vite application.

First, src/devtools.svelte.ts contains ordinary adapter code rather than a Svelte runes module. Its filename produces dist/esm/devtools.svelte.js, which TanStackDevtools.svelte imports directly. The consumer's Svelte Vite plugin recognizes the published .svelte.js suffix as a module for compileModule() and attempts to compile the already-generated JavaScript again.

That generated file contains an import from svelte/internal/client, so the consumer fails during Vite transformation with this compiler error:

Imports of `svelte/internal/*` are forbidden. It contains private runtime code which is subject to change without notice.

Applications can work around the failure by excluding the generated adapter from compileModule() and excluding @tanstack/svelte-devtools from dependency optimization. Those application-level exceptions should not be required to consume the published adapter.

Second, the package manifest declares a legacy top-level "svelte" field but its root export only defines an import condition. Svelte-aware tooling therefore warns that the package does not provide a svelte condition through exports.

These failures are independent, but they share the same published Svelte package boundary and can be covered by one minimal consumer fixture.

Expected behavior

A Svelte Vite application should import @tanstack/svelte-devtools without compileModule.exclude or optimizeDeps.exclude, without compiling generated adapter code a second time, and without an export-condition warning.

The ordinary adapter module should be published under an ordinary JavaScript filename, such as by renaming devtools.svelte.ts to devtools-adapter.ts and updating the component import. The root package export should also provide a svelte condition while preserving its existing type and standard import targets.

The package build, publint --strict, and a minimal Svelte consumer should verify the resulting artifact and resolution behavior.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

See termnial failures - https://stackblitz.com/edit/vitejs-vite-4fz8qn1y?file=package.json,index.html,vite.config.ts,tsconfig.json,src%2Fmain.ts,src%2FApp.svelte,src%2Fvite-env.d.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.