Environment
nitro-nightly 3.0.1-20260227-181935-bfbb207c (broken)
nitro-nightly 3.0.1-20260227-142232-5ccf672a (works — both from 2026-02-27)
@tanstack/react-start 1.162.9
vite 7.3.1
node 22
Reproduction
Minimal vite.config.ts:
import { defineConfig } from 'vite'
import { tanstackStart } from '@tanstack/react-start/plugin/vite'
import { nitro } from 'nitro/vite'
import viteReact from '@vitejs/plugin-react'
export default defineConfig({
plugins: [tanstackStart(), nitro(), viteReact()],
})
With a src/entry-client.tsx that looks like any standard TanStack Start client entry:
import { StartClient } from '@tanstack/react-start/client'
import { StrictMode } from 'react'
import { hydrateRoot } from 'react-dom/client'
hydrateRoot(document, <StrictMode><StartClient /></StrictMode>)
Describe the bug
After upgrading from the 142232 nightly to 181935, the client Rollup build input contains two entries instead of one:
{
"main": "virtual:tanstack-start-client-entry",
"index": "/absolute/path/to/src/entry-client.tsx"
}
Only main should be there. TanStack Start registers virtual:tanstack-start-client-entry → src/entry-client.tsx as an alias and sets environments.client.build.rollupOptions.input to { main: "virtual:tanstack-start-client-entry" }. The 181935 nightly then also picks up src/entry-client.tsx directly (via what looks like a scanDirs scan for entry-client.*) and adds it as a separate index input to the same environment. The client bundle ends up broken as a result.
Rolling back to the 142232 nightly or manually pinning the lockfile to it fixes it.
Additional context
The index key in the duplicate entry matches what createServiceEnvironment produces ({ input: { index: entry } }), so the regression is likely in the configEnvironment hook — either the early return for consumer === "client" environments was broken, or the client entry auto-detection now runs before or after that check in a way it didn't before.
There's no config-level workaround; renderer is excluded from NitroConfig/NitroPluginConfig so there's no way to suppress the discovery from userland.
Environment
Reproduction
Minimal vite.config.ts:
With a
src/entry-client.tsxthat looks like any standard TanStack Start client entry:Describe the bug
After upgrading from the
142232nightly to181935, the client Rollup build input contains two entries instead of one:{ "main": "virtual:tanstack-start-client-entry", "index": "/absolute/path/to/src/entry-client.tsx" }Only
mainshould be there. TanStack Start registersvirtual:tanstack-start-client-entry → src/entry-client.tsxas an alias and setsenvironments.client.build.rollupOptions.inputto{ main: "virtual:tanstack-start-client-entry" }. The181935nightly then also picks upsrc/entry-client.tsxdirectly (via what looks like a scanDirs scan forentry-client.*) and adds it as a separateindexinput to the same environment. The client bundle ends up broken as a result.Rolling back to the
142232nightly or manually pinning the lockfile to it fixes it.Additional context
The
indexkey in the duplicate entry matches whatcreateServiceEnvironmentproduces ({ input: { index: entry } }), so the regression is likely in theconfigEnvironmenthook — either the early return forconsumer === "client"environments was broken, or the client entry auto-detection now runs before or after that check in a way it didn't before.There's no config-level workaround;
rendereris excluded fromNitroConfig/NitroPluginConfigso there's no way to suppress the discovery from userland.