devtools-ui 0.7.0 breaks SSR boot with solid-js <=1.9.12: `use` is not exported by solid-js/web server build
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 499
- Forks
- 100
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 4
Description
TanStack Devtools version
@tanstack/devtools 0.14.0 / @tanstack/devtools-ui 0.7.0 (still present in 0.14.1 / 0.7.1, the latest at time of filing)
Framework/Library version
TanStack Start (@tanstack/react-start 1.168.x) + Vite 8 (rolldown) + @cloudflare/vite-plugin, solid-js 1.9.12 in the lockfile
Describe the bug
Upgrading @tanstack/devtools 0.13.0 → 0.14.0 (which bumps the bundled @tanstack/devtools-ui 0.6.0 → 0.7.0) makes vite dev fail to boot in any app whose SSR environment processes devtools, when the resolved solid-js is ≤ 1.9.12:
Error: Error during dependency optimization:
[MISSING_EXPORT] "use" is not exported by "node_modules/solid-js/web/dist/server.js".
╭─[ node_modules/@tanstack/devtools/node_modules/@tanstack/devtools-ui/dist/esm/components/theme.js:2:45 ]
│
2 │ import { createComponent, insert, template, use } from "solid-js/web";
│ ─┬─
│ ╰─── Missing export
The dev server never starts, which also takes down every Playwright run driven by vite dev.
Root cause
@tanstack/devtools-ui0.7.0 (PR #492, commit a46d1f5) wrappedThemeContextProvider's children in<span style="display:contents" ref={setContainer}>so it can callensureDevtoolsStyles(element.ownerDocument)(src/components/theme.tsx). The Solid compiler emits thatrefasuse(setContainer, _el$), so the published ESM (dist/esm/components/theme.js) now importsusefromsolid-js/web. In 0.6.0 that file imported onlycreateComponent.- Under the
node/SSR export condition,solid-js/webresolves toweb/dist/server.js. That server build exported nouseat all through solid-js 1.9.12; solid-js 1.9.13 (2026-05-15) added it as anotSupstub (notSup as use). @tanstack/devtools-uideclaressolid-js: >=1.9.7(and@tanstack/devtoolsdepends on^1.9.9), so resolvers happily keep ≤ 1.9.12 in existing lockfiles — a lockfile that worked with devtools 0.13.0 hard-fails right after the bump.
Client-only setups never hit it (the browser build has always exported use), which is presumably why it shipped unnoticed. It surfaces wherever the SSR side bundles or import-validates devtools — e.g. TanStack Start with rolldown-vite's SSR dependency optimizer.
Steps to reproduce
- Lockfile with
solid-js@1.9.12(any version ≥1.9.7 and ≤1.9.12 works) and@tanstack/devtools@0.14.x. - Import devtools in an app whose Vite SSR environment processes it (TanStack Start default setup is enough).
vite dev→MISSING_EXPORT "use"during SSR dependency optimization.
Or minimally, in any Node ESM context resolving the server condition:
import { use } from 'solid-js/web'; // solid-js@1.9.12, server condition → SyntaxError/MISSING_EXPORT
Suggested fix
Raise the solid-js floor to ^1.9.13 in @tanstack/devtools-ui's (and @tanstack/devtools's) dependency ranges, so resolvers pull a solid-js whose server build has the use stub. Alternatively avoid the ref → use emission in output that gets loaded under the server condition.
Workaround for affected users: force-dedupe solid-js to ≥ 1.9.13 (we removed the stale nested resolutions from the lockfile so a single hoisted 1.9.15 serves everything; that fixes the boot).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/components/theme.tsx and reproduce the SSR dependency-optimization failure using solid-js 1.9.12 and the minimal server-condition import described in the issue. Resolve the published package compatibility problem, then verify that vite dev boots for an SSR setup with the affected dependency range and that the missing-export error no longer occurs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, vite
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100